Perché archiviare i collegamenti self e parent (. E ..) in una voce della directory?

11

Prendi in considerazione un file system destinato ad alcuni dispositivi incorporati che fa poco più che archiviare i file in una struttura di directory gerarchica. Questo file system manca di molte delle operazioni a cui potresti essere abituato in sistemi come unix e Windows (ad esempio, le sue autorizzazioni di accesso sono completamente diverse e non legate ai metadati memorizzati nelle directory). Questo filesystem non consente alcun tipo di hard link o soft link, quindi ogni file ha un nome univoco in una struttura ad albero rigorosa.

C'è qualche vantaggio nella memorizzazione di un collegamento alla directory stessa e al suo genitore nella struttura dei dati su disco che rappresenta una directory?

La maggior parte dei filesystem unix ha .e ..voci sul disco. Mi chiedo perché non gestiscano quelli a livello VFS (driver di filesystem generico). È un artefatto storico? C'è una buona ragione, e se sì, quale precisamente, così posso determinare se è rilevante per il mio sistema incorporato?

operating-systems filesystems

— Gilles 'SO- smetti di essere malvagio'
fonte

Ho sempre pensato che fossero lì solo virtualmente in modo che i programmi potessero accedere facilmente alla directory corrente e parent. Domanda interessante, ma appartiene qui?

— Raffaello

@Raphael Potrei capire se hai considerato la mia domanda troppo ampia (→ "non una vera domanda"), o forse "non costruttiva", perché è in qualche modo aperta. Ma non sono d'accordo sul fatto che sia fuori tema: riguarda la progettazione del filesystem, come può non essere applicata l'informatica? Se ritieni che sia fuori tema, spiega il tuo ragionamento su meta.

— Gilles 'SO- smetti di essere malvagio' l'

@Raphael Ho modificato la mia domanda, speriamo che dovrebbe essere chiaro che il mio punto di vista è quello di un progettista di sistemi operativi embedded. Grazie per i tuoi commenti

— Gilles 'SO- smetti di essere malvagio' il

2

Avere collegamenti alla directory principale ha senso per me. Se non li avessi, dovrai sempre lavorare con un intero elenco di directory. Quindi, per esempio, /home/svick/Documents/dovrebbe essere rappresentato come { /, /home/, /home/svick/, /home/svick/Documents }. Se non lo facessi, non saresti in grado di trovare la directory principale (o sarebbe molto costoso). Questo non è solo inefficiente, ma anche pericoloso. Se hai due di questi elenchi che si sovrappongono, potrebbero facilmente desincronizzarsi se spostassi qualche directory.

D'altra parte, se si ha un riferimento alla directory principale, è più efficiente e più sicuro.

Non vedo alcun motivo per avere effettivamente un collegamento alla directory corrente. Se si dispone di una struttura che rappresenta una directory e si desidera accedere a tale directory, l'utilizzo .è sempre del tutto superfluo. Per questo motivo, mi aspetto che il .collegamento non esista effettivamente nella struttura del filesystem ed è solo virtuale.

— svick
fonte

2

Stessa osservazione: perché farlo in ciascun filesystem piuttosto che nel livello VFS? La maggior parte dei filesystem Linux ha .e ..voci.

— Gilles 'SO-smetti di essere malvagio' il

Come ho detto, penso che sia più efficiente. Puoi lavorare solo con la directory corrente e accedere ai suoi genitori solo quando ne hai bisogno. Se non si disponessero di collegamenti principali, sarà sempre necessario mantenere tutte le directory dell'intero percorso dalla radice in memoria. E ne avresti bisogno per ogni voce che usi.

— svick

1

@svick: Gilles non confronta i collegamenti principali con i collegamenti principali. Paragona il fatto di averli nel file system effettivo con il fatto di averli simulati da uno strato intermedio di codice (vfs) tra il file system effettivo e lo spazio utente.

— rgrig

2

Ottieni meno casi speciali. In molte situazioni, VFS può gestire ".." poiché gestisce qualsiasi altro nome di directory.

— rgrig
fonte

3

Se le directory sono virtuali, il programma (presumo usermode) può ancora gestirlo come qualsiasi altra directory. Non hai davvero bisogno dei link per presentare a livello di archiviazione.

— Aryabhata,

1

Sì, ma perché non gestirlo a livello VFS? Perché dovrebbe esserci spazio di archiviazione associato?

— Gilles 'SO- smetti di essere malvagio' il

Perché le persone implementano elenchi collegati con una sentinella invece di occuparsi del caso elenco vuoto nelle funzioni di aggiunta / rimozione?

— venerdì

@rgrig: succede solo quando l'interfaccia per l'implementazione dell'elenco collegato considerato è scritta in un linguaggio che è eccezionalmente cattivo nella gestione delle strutture di dati induttivi (C, Java, ecc ...). Qui questo problema non è rilevante perché il livello VFS non è direttamente accessibile dal punto di vista dell'utente.

— Stéphane Gimenez,

@ StéphaneGimenez: questo problema è rilevante, perché VFS è scritto in C.

— rgrig

2

L'unica ragione che posso immaginare è il seguente scenario:

Un'implementazione originale di un file system esisteva con lo stesso formato di directory ma le nozioni di percorsi di file e sottodirectory non erano considerate in quel momento (Vedi il file system Unix PDP-7 ).
Quindi le persone hanno pensato che la risoluzione del percorso e le sottodirectory sarebbero state utili!
Per mantenere una certa compatibilità con le versioni precedenti, è stato deciso che .e ..sarà archiviato sul disco come qualsiasi altra directory.

Quindi forse ci rimangono quei manufatti inutili, solo per motivi di retrocompatibilità con software di 40 anni? Scenario credibile?

Nota: Inoltre, non è stato del tutto stupido aggiungere queste voci all'elenco delle directory, in quanto è comunque necessario memorizzare il numero di inode della directory del vero genitore da qualche parte (ricordare che al momento erano consentiti collegamenti fissi alle directory) e un riferimento al proprio il proprio numero di inode potrebbe essere un buon controllo di integrità.

— Stéphane Gimenez
fonte

1

Non vedo un motivo per implementare .e ..su entrambi i livelli piuttosto che sull'altro. Tuttavia, se scegli come target dei sistemi embedded qualsiasi livello che puoi risparmiare potrebbe essere guadagnato in dollari, quindi potrebbe avere senso cercare di implementare tutto il più basso possibile.

Per quanto riguarda il bisogno generale di .e .., come esprimeresti percorsi relativi senza di loro? Almeno ..è indispensabile per i percorsi che lasciano la sottostruttura corrente. Se non hai bisogno di tali percorsi (forse l'albero è un modo primitivo per codificare i privilegi di accesso?) Non ti serve ...

— Raffaello
fonte