| (One intermediate revision by one other user not shown) | |||
| Line 4: | Line 4: | ||
== Sommario == | == Sommario == | ||
Fornire una modalità per montare in sola lettura quasi l'intero sistema operativo installato, in modo da effettuare automaticamente snapshot, o condividerlo tra host multipli al fine di ridurre spazio e | Fornire una modalità per montare in sola lettura quasi l'intero sistema operativo installato, in modo da effettuare automaticamente snapshot, o condividerlo tra host multipli al fine di ridurre spazio e manutenzione. Invece di diffondere il contenuto dei pacchetti RPM in tutto lo spazio del filesystem, ed artificialmente separare ''/bin'' da ''/usr/bin'' e ''/lib'' da ''/usr/lib'', si sposta tutto il contenuto in ''/usr'', fornendo soltanto link simbolici nel filesystem radice. | ||
''/usr'' nel proprio filesystem fornisce molte preziose opzioni per le impostazioni personalizzate. Per ragioni storiche, si sono separati molti strumenti da ''/usr'' e spostati in ''/''. Ma, le caratteristiche avanzate nei sistemi attuali non possono realmente condurre ad una ''/usr'' vuota. Sempre più rientrano in modo labile in tali impostazioni. | ''/usr'' nel proprio filesystem fornisce molte preziose opzioni per le impostazioni personalizzate. Per ragioni storiche, si sono separati molti strumenti da ''/usr'' e spostati in ''/''. Ma, le caratteristiche avanzate nei sistemi attuali non possono realmente condurre ad una ''/usr'' vuota. Sempre più rientrano in modo labile in tali impostazioni. | ||
| Line 23: | Line 23: | ||
Non esiste un modo per allevare in modo affidabile un sistema moderno con una /usr vuota; le alternative sono due: copiare /usr nel rootfs o usare una initramfs che mascheri la separazione dal sistema. | Non esiste un modo per allevare in modo affidabile un sistema moderno con una /usr vuota; le alternative sono due: copiare /usr nel rootfs o usare una initramfs che mascheri la separazione dal sistema. | ||
Storicamente, /bin, /sbin, /lib avevano il proposito di contenere gli strumenti per montare /usr. Tale ruolo ora può essere conferito ad initramfs. | Storicamente, /bin, /sbin, /lib avevano il proposito di contenere gli strumenti per montare /usr. Tale ruolo ora può essere conferito ad initramfs. Poiché l'initramfs sa dove trovare la partizione di root (che include /etc), esso può analizzare /etc/fstab ed altri file di configurazione e montare /usr prima di attivare la partizione di root ed eseguire /usr/bin/init. Da questo punto in poi, init monta le partizioni rimanenti in /etc/fstab ed il sistema si avvia come al solito. | ||
Il piano di lungo periodo è di rimettere ordine nella confusione creata dall'attuale separazione tra / e /usr. Tutti gli strumenti ritorneranno in /usr dove essi appartengono, ed il rootfs conterrà soltanto link simbolici a /usr. Quasi l'intero sistema installato di pacchetti | Il piano di lungo periodo è di rimettere ordine nella confusione creata dall'attuale separazione tra / e /usr. Tutti gli strumenti ritorneranno in /usr dove essi appartengono, ed il rootfs conterrà soltanto link simbolici a /usr. Quasi l'intero sistema installato di pacchetti risiederà in /usr. Ciò separerà tutti i dati non host specifici in /usr. /usr può quindi essere vista come la partizione delle risorse di sistema Unix (/System), che definisce il sistema operativo di base (p.e. F18 o RHEL-7). | ||
Questa nuova /usr, per impostazione predefinita, potrebbe essere montata in sola lettura, mentre la rootfs è montata in lettura-scrittura e contiene soltanto punti di montaggio vuoti, link simbolici a /usr e i dati host specifici come /etc, /root, /srv. Rispetto alle impostazioni attuali, il rootfs sarà molto piccolo. La nuova /usr potrebbe anche essere facilmente condivisa in sola lettura tra diversi sistemi, e potrebbe contenere quasi l'intero sistema. Tali impostazioni sono molto | Questa nuova /usr, per impostazione predefinita, potrebbe essere montata in sola lettura, mentre la rootfs è montata in lettura-scrittura e contiene soltanto punti di montaggio vuoti, link simbolici a /usr e i dati host specifici come /etc, /root, /srv. Rispetto alle impostazioni attuali, il rootfs sarà molto piccolo. La nuova /usr potrebbe anche essere facilmente condivisa in sola lettura tra diversi sistemi, e potrebbe contenere quasi l'intero sistema. Tali impostazioni sono molto efficienti, in grado di fornire maggiore sicurezza, maggiore flessibilità, maggiori valide opzioni per impostazioni personalizzate, e risultano più semplici da configurare e mantenere. | ||
Tutto ciò, lascia le seguenti directory ben definite, che compongono la base del sistema: | Tutto ciò, lascia le seguenti directory ben definite, che compongono la base del sistema: | ||
| Line 60: | Line 60: | ||
* La possibilità di condividere /usr è utile soprattutto a macchine virtuali e cluster. | * La possibilità di condividere /usr è utile soprattutto a macchine virtuali e cluster. | ||
* La possibilità di montare /usr in sola lettura (p.e. su supporti in sola lettura) può aggiungere sicurezza alla macchina. | * La possibilità di montare /usr in sola lettura (p.e. su supporti in sola lettura) può aggiungere sicurezza alla macchina. | ||
* L'intera /usr può essere sicuramente | * L'intera /usr può essere sicuramente fotografata durante gli upgrade. | ||
== How To Test == | == How To Test == | ||
Fare riferimento alla [[Features/UsrMove#How To Test |versione originale di questo documento]]. | |||
== Esperienza utente == | |||
== | |||
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
Fare riferimento alla [[Features/UsrMove#User Experience |versione originale di questo documento]]. | |||
== | == Dipendenze == | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | ||
Fare riferimento alla [[Features/UsrMove#Dependencies |versione originale di questo documento]]. | |||
== Roadmap == | == Roadmap == | ||
Fare riferimento alla [[Features/UsrMove#Roadmap |versione originale di questo documento]]. | |||
=== Buildsystem Transition === | === Buildsystem Transition === | ||
Fare riferimento alla [[Features/UsrMove#Buildsystem Transition |versione originale di questo documento]]. | |||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
Fare riferimento alla [[Features/UsrMove#Contingency Plan |versione originale di questo documento]]. | |||
== Documentazione == | == Documentazione == | ||
| Line 171: | Line 99: | ||
** [http://heise.de/-1371441 Heise - german only] | ** [http://heise.de/-1371441 Heise - german only] | ||
== | == Note di rilascio == | ||
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | <!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | ||
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --> | <!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --> | ||
== | Fare riferimento alla [[Features/UsrMove#Release Notes |versione originale di questo documento]]. | ||
== Commenti and Discussioni == | |||
* See [[Talk:Features/UsrMove]] | * See [[Talk:Features/UsrMove]] | ||
=== FAQ === | === FAQ === | ||
==== Quale problema si sta | ==== Quale problema si sta cercando di risolvere? ==== | ||
Si vuole rendere /usr condivisibile in un modo sano. | Si vuole rendere /usr condivisibile in un modo sano. | ||
| Line 198: | Line 121: | ||
==== Non ho una partizione separata di /usr. Cosa cambia per me? ==== | ==== Non ho una partizione separata di /usr. Cosa cambia per me? ==== | ||
Non cambia nessuna funzionalità. Tutti i vecchi path sono raggiungibili, | Non cambia nessuna funzionalità. Tutti i vecchi path sono raggiungibili, poiché esistono symlink compatibili che non sono stati rimossi (almeno per il momento). Tutti gli script e i binari dovrebbero funzionare come prima. Per il processo di aggiornamento, si troveranno /sbin, /bin, /lib e /lib64 contenenti soprattutto link simbolici. Nel breve, poiché queste directory contengono '''soltanto''' link simbolici, l'intera directory verrà sostituita da un solo link simbolico. Questi tre o quattro link simbolici di alto livello resteranno lì fintanto che l'ABI di elf loader di linux è definito da “/lib/ld-linux.so.2” o dalla controparte di architettura specifica come “/lib64/ld-linux-x86-64.so.2” e fintanto che gli script usano “#!/bin/sh”. | ||
==== Ho una partizione separata di /usr. Cosa cambia per me? ==== | ==== Ho una partizione separata di /usr. Cosa cambia per me? ==== | ||
Non si è sicuri di come sia stato fatto ciò. In generale, avere | Non si è sicuri di come sia stato fatto ciò. In generale, avere una partizione /usr separata non funziona, per il momento. | ||
Consultare http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. | Consultare http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. | ||
Ma con l'implementazione di questa caratteristica, le cose ritorneranno ad un modo sano e supportato di avere un punto di mount /usr. | Ma con l'implementazione di questa caratteristica, le cose ritorneranno ad un modo sano e supportato di avere un punto di mount /usr. | ||
==== | ==== Perché non risolvere la situazione attuale con /usr, ponendo tutti i binari rilevanti in /bin /sbin /lib e /lib64? ==== | ||
e | In quel caso si condividerebbe la gerarchia delle directory top-level presso tutit gli host. Essi dovrebbero montare /etc e /var per veriosni host-only. SOprattutto /etc/fstab non sarebbe accessibile senza l'aggiunta di informazioni aggiuntive in initramfs. Per ogni directory top-level host-only, come /opt oppure /srv, si necessiterebbe di un mount point. | ||
==== Quindi, | |||
==== Quindi, perché non montare proprio /usr dall'initramfs e lasciare i file dove sono? ==== | |||
Va bene, allora si immagini di avere una /usr montata da una locazione di rete e si desideri aggiornare un pacchetto. Probabilmente si monterà la copia principale di /usr sulla macchina principale e si aggiornerà /usr con il manutentore di pacchetti. Poi si provvede ad una nuova copia della /usr principale sulle altre macchine, in fase di reboot. Ora tutte hanno la nuova /usr aggiornata. Ma che si può dire di /sbin /bin /lib e /lib64? Esse contengono ancora i vecchi binari. Per loro non esiste nessun aggiornamento di sicurezza di glibc. Perciò ogni macchina deve aggiornare queste directory via rsync o simile (rpm non funziona con una /usr in sola lettura). Ciò duplica la manutenzione di tenere entrambe le parti in sync. | Va bene, allora si immagini di avere una /usr montata da una locazione di rete e si desideri aggiornare un pacchetto. Probabilmente si monterà la copia principale di /usr sulla macchina principale e si aggiornerà /usr con il manutentore di pacchetti. Poi si provvede ad una nuova copia della /usr principale sulle altre macchine, in fase di reboot. Ora tutte hanno la nuova /usr aggiornata. Ma che si può dire di /sbin /bin /lib e /lib64? Esse contengono ancora i vecchi binari. Per loro non esiste nessun aggiornamento di sicurezza di glibc. Perciò ogni macchina deve aggiornare queste directory via rsync o simile (rpm non funziona con una /usr in sola lettura). Ciò duplica la manutenzione di tenere entrambe le parti in sync. | ||
==== Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante! ==== | ==== Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante! ==== | ||
Il filesystem più critico è /boot, | Il filesystem più critico è /boot, perché il kernel vive qui. Perciò il proposito di avere /bin ed /sbin per riparare /usr si basava su _due_ filesystem funzionanti (/ e /boot). Se entrambi erano non funzionanti, non si era capaci di recuperare la /usr. Il ruolo del sistema di ripristino può essere facilmente coperto da una iniramfs di ripristino. Perciò avere la iniramfs di ripristino in /boot, contenente gli strumenti di fsck, incorre nello stesso pericolo di diventare corrotta del kernel. In questo modo basta tirar fuori il CD di ripristino, se la /boot è corrotta e invece no se è corrotta la /. | ||
==== Quindi, si condivide /bin /sbin /lib /lib64 e /usr e si montano tutti da initramfs! ==== | ==== Quindi, si condivide /bin /sbin /lib /lib64 e /usr e si montano tutti da initramfs! ==== | ||
Ora, inizi ad avere la sensazione che muovere ogni cosa in /usr potrebbe rendere le cose più semplici ... | Ora, inizi ad avere la sensazione che muovere ogni cosa in /usr potrebbe rendere le cose più semplici ... | ||
==== | ==== Perché non spostare tutto il contenuto di /usr in / e dimenticarsi di /usr? ==== | ||
Perché ciò introduce un gran numero di nuove directory di alto livello, che devono essere punti di montaggio da essere condivisi con altri host. | |||
==== Ok, ma che si può dire di un root filesystem di rete e di un filesystem montato localmente? ==== | ==== Ok, ma che si può dire di un root filesystem di rete e di un filesystem montato localmente? ==== | ||
In tal caso si vuole condividere la gerarchia di directory di livello superiore tra tutti gli host. Gli host | In tal caso si vuole condividere la gerarchia di directory di livello superiore tra tutti gli host. Gli host monterebbero /etc e /var per le versioni solo host. In particolare /etc/fstab non è accessibile, senza aggiungere informazione all'initramfs su come montarlo. Per ogni host con con directory addizionali come /opt ed /srv, si dovrebbe avere un punto di mount. | ||
Latest revision as of 14:23, 20 January 2016
Spostamento di tutto in /usr
Sommario
Fornire una modalità per montare in sola lettura quasi l'intero sistema operativo installato, in modo da effettuare automaticamente snapshot, o condividerlo tra host multipli al fine di ridurre spazio e manutenzione. Invece di diffondere il contenuto dei pacchetti RPM in tutto lo spazio del filesystem, ed artificialmente separare /bin da /usr/bin e /lib da /usr/lib, si sposta tutto il contenuto in /usr, fornendo soltanto link simbolici nel filesystem radice.
/usr nel proprio filesystem fornisce molte preziose opzioni per le impostazioni personalizzate. Per ragioni storiche, si sono separati molti strumenti da /usr e spostati in /. Ma, le caratteristiche avanzate nei sistemi attuali non possono realmente condurre ad una /usr vuota. Sempre più rientrano in modo labile in tali impostazioni.
Invece di spostare altri strumenti in /, allo stato attuale si richiede che /usr sia montata da initramfs, per essere disponibile prima dell'effettivo avvio di 'init'. La separazione del filesystem di root su /usr, in Linux, non serve ad alcun proposito ma complica o previene impostazioni semplici e più flessibili.
Manutentore
- Nome: Harald Hoyer
- Email: harald@redhat.com
- Nome: Kay Sievers
- Email: kay@redhat.com
Stato corrente
Consultare la versione originale.
Descrizione dettagliata
Non esiste un modo per allevare in modo affidabile un sistema moderno con una /usr vuota; le alternative sono due: copiare /usr nel rootfs o usare una initramfs che mascheri la separazione dal sistema.
Storicamente, /bin, /sbin, /lib avevano il proposito di contenere gli strumenti per montare /usr. Tale ruolo ora può essere conferito ad initramfs. Poiché l'initramfs sa dove trovare la partizione di root (che include /etc), esso può analizzare /etc/fstab ed altri file di configurazione e montare /usr prima di attivare la partizione di root ed eseguire /usr/bin/init. Da questo punto in poi, init monta le partizioni rimanenti in /etc/fstab ed il sistema si avvia come al solito.
Il piano di lungo periodo è di rimettere ordine nella confusione creata dall'attuale separazione tra / e /usr. Tutti gli strumenti ritorneranno in /usr dove essi appartengono, ed il rootfs conterrà soltanto link simbolici a /usr. Quasi l'intero sistema installato di pacchetti risiederà in /usr. Ciò separerà tutti i dati non host specifici in /usr. /usr può quindi essere vista come la partizione delle risorse di sistema Unix (/System), che definisce il sistema operativo di base (p.e. F18 o RHEL-7).
Questa nuova /usr, per impostazione predefinita, potrebbe essere montata in sola lettura, mentre la rootfs è montata in lettura-scrittura e contiene soltanto punti di montaggio vuoti, link simbolici a /usr e i dati host specifici come /etc, /root, /srv. Rispetto alle impostazioni attuali, il rootfs sarà molto piccolo. La nuova /usr potrebbe anche essere facilmente condivisa in sola lettura tra diversi sistemi, e potrebbe contenere quasi l'intero sistema. Tali impostazioni sono molto efficienti, in grado di fornire maggiore sicurezza, maggiore flessibilità, maggiori valide opzioni per impostazioni personalizzate, e risultano più semplici da configurare e mantenere.
Tutto ciò, lascia le seguenti directory ben definite, che compongono la base del sistema:
- /usr - sistema installato; condivisibile; possibilmente in sola lettura;
- /etc - dati di configurazione; non-condivisibile;
- /var - dati persistenti; non-condivisibile;
- /run - dati temporanei; non-condivisibile; filesystem tmpfs obbligatorio.
/ |-- etc |-- usr | |-- bin | |-- sbin | |-- lib | `-- lib64 |-- run |-- var |-- bin -> usr/bin |-- sbin -> usr/sbin |-- lib -> usr/lib `-- lib64 -> usr/lib64
Vantaggi per Fedora
- Layout di file system più semplice e pulito, con piena compatibilità
- Chiara separazione di risorse specifiche tra sistema operativo e host
- Migliore compatibilità possibile, nessuna confusione sulle locazioni degli strumenti di installazione, nessun $PATH fiddling, tutti i possibili path ad un binario funzioneranno sempre.
Scope
- La possibilità di condividere /usr è utile soprattutto a macchine virtuali e cluster.
- La possibilità di montare /usr in sola lettura (p.e. su supporti in sola lettura) può aggiungere sicurezza alla macchina.
- L'intera /usr può essere sicuramente fotografata durante gli upgrade.
How To Test
Fare riferimento alla versione originale di questo documento.
Esperienza utente
Fare riferimento alla versione originale di questo documento.
Dipendenze
Fare riferimento alla versione originale di questo documento.
Roadmap
Fare riferimento alla versione originale di questo documento.
Buildsystem Transition
Fare riferimento alla versione originale di questo documento.
Contingency Plan
Fare riferimento alla versione originale di questo documento.
Documentazione
- Questa pagina è la fonte primaria di documentazione.
- Solaris (possiede lo stesso modello da anni)
- Why /usr on a separate partition is broken currently
- Discussion on fedora-devel
- Proposal for openSUSE
- Discussion on debian-devel
- Discussion on gentoo-devel e successivi thread su udev e /usr
- Discussion on slashdot
- Media
Note di rilascio
Fare riferimento alla versione originale di questo documento.
Commenti and Discussioni
FAQ
Quale problema si sta cercando di risolvere?
Si vuole rendere /usr condivisibile in un modo sano.
Ulteriori benefici di questa caratteristica sono:
- minore confusione nel file system
- se si crea uno snapshot di /usr prima di un aggiornamento, si crea con un colpo solo lo snapshot del sistema operativo.
Cos'è che attualmente non funziona con l'avere una partizione separata di /usr?
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Non ho una partizione separata di /usr. Cosa cambia per me?
Non cambia nessuna funzionalità. Tutti i vecchi path sono raggiungibili, poiché esistono symlink compatibili che non sono stati rimossi (almeno per il momento). Tutti gli script e i binari dovrebbero funzionare come prima. Per il processo di aggiornamento, si troveranno /sbin, /bin, /lib e /lib64 contenenti soprattutto link simbolici. Nel breve, poiché queste directory contengono soltanto link simbolici, l'intera directory verrà sostituita da un solo link simbolico. Questi tre o quattro link simbolici di alto livello resteranno lì fintanto che l'ABI di elf loader di linux è definito da “/lib/ld-linux.so.2” o dalla controparte di architettura specifica come “/lib64/ld-linux-x86-64.so.2” e fintanto che gli script usano “#!/bin/sh”.
Ho una partizione separata di /usr. Cosa cambia per me?
Non si è sicuri di come sia stato fatto ciò. In generale, avere una partizione /usr separata non funziona, per il momento. Consultare http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. Ma con l'implementazione di questa caratteristica, le cose ritorneranno ad un modo sano e supportato di avere un punto di mount /usr.
Perché non risolvere la situazione attuale con /usr, ponendo tutti i binari rilevanti in /bin /sbin /lib e /lib64?
In quel caso si condividerebbe la gerarchia delle directory top-level presso tutit gli host. Essi dovrebbero montare /etc e /var per veriosni host-only. SOprattutto /etc/fstab non sarebbe accessibile senza l'aggiunta di informazioni aggiuntive in initramfs. Per ogni directory top-level host-only, come /opt oppure /srv, si necessiterebbe di un mount point.
Quindi, perché non montare proprio /usr dall'initramfs e lasciare i file dove sono?
Va bene, allora si immagini di avere una /usr montata da una locazione di rete e si desideri aggiornare un pacchetto. Probabilmente si monterà la copia principale di /usr sulla macchina principale e si aggiornerà /usr con il manutentore di pacchetti. Poi si provvede ad una nuova copia della /usr principale sulle altre macchine, in fase di reboot. Ora tutte hanno la nuova /usr aggiornata. Ma che si può dire di /sbin /bin /lib e /lib64? Esse contengono ancora i vecchi binari. Per loro non esiste nessun aggiornamento di sicurezza di glibc. Perciò ogni macchina deve aggiornare queste directory via rsync o simile (rpm non funziona con una /usr in sola lettura). Ciò duplica la manutenzione di tenere entrambe le parti in sync.
Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante!
Il filesystem più critico è /boot, perché il kernel vive qui. Perciò il proposito di avere /bin ed /sbin per riparare /usr si basava su _due_ filesystem funzionanti (/ e /boot). Se entrambi erano non funzionanti, non si era capaci di recuperare la /usr. Il ruolo del sistema di ripristino può essere facilmente coperto da una iniramfs di ripristino. Perciò avere la iniramfs di ripristino in /boot, contenente gli strumenti di fsck, incorre nello stesso pericolo di diventare corrotta del kernel. In questo modo basta tirar fuori il CD di ripristino, se la /boot è corrotta e invece no se è corrotta la /.
Quindi, si condivide /bin /sbin /lib /lib64 e /usr e si montano tutti da initramfs!
Ora, inizi ad avere la sensazione che muovere ogni cosa in /usr potrebbe rendere le cose più semplici ...
Perché non spostare tutto il contenuto di /usr in / e dimenticarsi di /usr?
Perché ciò introduce un gran numero di nuove directory di alto livello, che devono essere punti di montaggio da essere condivisi con altri host.
Ok, ma che si può dire di un root filesystem di rete e di un filesystem montato localmente?
In tal caso si vuole condividere la gerarchia di directory di livello superiore tra tutti gli host. Gli host monterebbero /etc e /var per le versioni solo host. In particolare /etc/fstab non è accessibile, senza aggiungere informazione all'initramfs su come montarlo. Per ogni host con con directory addizionali come /opt ed /srv, si dovrebbe avere un punto di mount.