Unionfs vs Aufs vs Overlayfs vs mhddfs, quale utilizzo


15

Ho letto a caso sul file system union che consente a un utente di montare simultaneamente più filesystem uno sull'altro.

Tuttavia, sto trovando difficoltà a decidere quale utilizzare (Unionfs vs Aufs vs Overlayfs vs mhddfs) e perché non ho trovato informazioni concrete sull'argomento da nessuna parte. So ad esempio che overlayFS è stato adottato nel kernel Linux tradizionale, il che significa che potrebbe ottenere un'adozione più ampia. Gradirei se qualcuno mi desse una prospettiva.

Inoltre, non riesco a trovare alcun caso d'uso concepito per il file system Union su qualcosa come LVM (come raccomandato dagli utenti in una domanda separata ) o la configurazione RAID, tranne nel fatto che LVM richiede la formattazione di tutte le unità che potrebbero non essere desiderabili se già avere dati preziosi sulle unità.


Risposte:


4

Ecco alcuni pensieri: lo sto ancora imparando e lo aggiornerò man mano che procederò.

Come scegliere il filesystem union

Esistono due modi per esaminare questo:

  • Come si confrontano le caratteristiche di ognuno?
  • Per alcuni casi d'uso comuni, quale dovrei scegliere?

Confronterò unionfs / unionfs-fuse / overlayfs / aufs / mergerfs, quest'ultimo sostituendo i mhddfs.

Caratteristiche di ciascuno

Stato di sviluppo

Supporto distribuzione / kernel

Esistono file system in modalità kernel e filesystem mode, quest'ultimo eseguito su FUSE. Quelli in modalità kernel hanno un sovraccarico minore (c'è un sovraccarico quando il codice passa tra spazio utente e spazio del kernel) ma l'unico attualmente supportato nel kernel Linux è overlayfs . I filesystem in modalità utente sono più facili da distribuire per le distribuzioni.

  • unionfs e aufs necessitano di patch del kernel
  • unionfs non è distribuito da Debian (il resto lo è)
  • unionfs-fuse e mergerfs sono basati su FUSE, quindi non sono necessari moduli aggiuntivi nel kernel
  • overlayfs fa parte del kernel dalla 3.18 (Debian Stretch)

Copia su scrittura

Questo si riferisce al caso d'uso del Live CD di seguito:

  • mergerfs non ha copia in scrittura
  • Lo fanno gli altri

Casi d'uso

Radice di sola lettura / Caso d'uso di Live CD

L'idea è di avere un CD-ROM / partizione di sola lettura di un sistema Linux. Il filesystem union lo fa sembrare all'utente come se fosse un sistema di lettura / scrittura in modo che possano apportare modifiche. Esiste un filesystem in lettura / scrittura (ad esempio un disco RAM tmpfs) che memorizza il "Delta" di tutte le modifiche apportate dall'utente, ma non l'istantanea completa.

Qui farebbe uno qualsiasi dei filesystem union.

Caso d'uso Docker

Sono consapevole che si tratta di un caso d'uso principale, ma non conosco i dettagli: qualcuno può fornire indicazioni in merito?

Unione di dischi rigidi

Ad esempio, potresti avere due set di /homedirectory su diversi filesystem. Oppure potresti aggiornare il tuo computer di casa con un secondo disco rigido e desideri un singolo volume logico.

Qui è dove non si desidera effettivamente copia su scrittura, quindi probabilmente le fusioni sono la scelta migliore.

File system Union rispetto a LVM per il pooling dei dischi

Elencherò alcuni casi d'uso che possono essere raggiunti con i filesystem union ma non con LVM:

Se si sta aggiornando un sistema esistente con un secondo disco, qualcosa come le fusioni potrebbe essere migliore perché LVM richiederebbe di riformattare il primo disco rigido, distruggendo quindi i dati su di esso. Un filesystem sindacale eviterebbe questo passaggio.

LVM potrebbe dividere un file su due dischi rigidi fisici (presupponendo RAID 0), quindi si perderà se un disco rigido si guasta.

Alcuni utenti potrebbero, ad esempio, conservare la propria /homedirectory su una chiavetta USB che possono portare via.

Nel caso d'uso di una partizione virtuale su due dischi fisici, con LVM non dovrai preoccuparti se i file vengono salvati su un disco o sull'altro. Con mergefs, il sistema può scegliere automaticamente quale scegliere per te in base alla quantità di spazio libero disponibile.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.