Perché ci sono così tanti progetti di filesystem in competizione? [chiuso]

Pensiamo alle specifiche qui per un momento, usando gli esempi che hai citato:

• ntfs - Proprietario di Microsoft. Chiunque non sia Microsoft non può usarlo, quindi dovrebbe usare / creare qualcosa di diverso. Ora, se sei Microsoft, vuoi usare questo su FAT a causa dei problemi del prossimo punto elenco.

• fat32 - Non sufficientemente moderno. La dimensione massima del file è 4 GB. La ricerca di voci di directory è O (n). La tabella di allocazione è una lista collegata, piuttosto che qualcosa di più efficiente come una bitmap di allocazione (dove è molto veloce trovare uno spazio libero contiguo). Non supporta i permessi. Non supporta collegamenti fisici o collegamenti simbolici. Non supporta l'inserimento nel journal.

• ext3 - Questa era un'estensione di ext2 principalmente per supportare l'inserimento nel diario.

Quindi, sembra che ci siano alcuni motivi:

1. Un filesystem precedente manca di qualcosa. Nel caso della FAT manca molto: sia in termini di (1) caratteristiche che (2) prestazioni. Nel caso di ext2 non aveva aggiornamenti su journall, quindi il recupero da un crash richiedeva più tempo.

2. Un filesystem esistente probabilmente lo farebbe, ma non è tuo. (ad esempio NTFS se non sei Microsoft). In questo caso non hai davvero molta scelta, ma per trovare il tuo.

Risposta breve: una taglia non è adatta a tutti.

Ci sono dei compromessi. Ad esempio, se si desidera una registrazione su giornale, si paga (efficienza, complessità, ecc.) Ma si ottiene qualcosa da esso. Alcuni non sentono il bisogno di un giornale registrato e non vogliono pagare per questo, alcuni lo fanno. Lo stesso con altre "caratteristiche" delle FS.

Non ci può mai essere un "migliore" di qualsiasi cosa, perché ci sono così tante opinioni su cosa sia "meglio". La decisione è specifica per le esigenze e le limitazioni dell'utente. I design sono sempre basati sulla loro capacità di adattarsi ai vincoli.

Un telefono cellulare di base deve memorizzare alcune centinaia di contatti, la cronologia dei messaggi di testo e alcune piccole app. Il suo filesystem deve supportare una struttura di directory gerarchica su unità multi-terabyte in una configurazione RAID? C'è sufficiente RAM sul dispositivo per eseguire un tale file system? Il filesystem richiede ACL complessi? Probabilmente no - per tutte queste domande - quindi sarebbe sufficiente un semplice file system che assorba le risorse.

Le aziende svilupperanno anche prodotti diversi per mantenere un vantaggio competitivo. Ad esempio, Apple apprezza la capacità del suo file system HFS + di tenere traccia dei file modificati di recente, in modo che i backup siano rapidi. D'altra parte, i driver per un floppy disk filesystem (FAT) possono contenere solo pochi KB di memoria.

Troppo dipende da cosa vuoi ottimizzare.

Considera la FAT per un momento: il suo supporto per i nomi di file lunghi è kludgy (per dirla in modo carino), e la ricerca attraverso i file in una directory è lineare quindi diventa molto rapidamente se una directory contiene un sacco di file. Allo stesso tempo, ha un minimo di metadati per la velocità di scrittura grezza è molto buona, e dal momento che è così semplice su tutto, il codice per implementarlo può essere piuttosto piccolo.

Qualcosa come ext2 o ext3 aggiunge molte funzionalità e funzionalità che sono semplicemente assenti dal FAT. Anche la ricerca di file è molto più veloce. Allo stesso tempo, la velocità di scrittura non elaborata è probabilmente un po 'più lenta, e il codice per implementare il file system è indubbiamente molto più grande.

Just a quick question, but why are there so many file systems still competing and in use today? (ntfs, fat32, ext3(ffs), etc)

It seems that file system designers could agree upon the best aspects of each type of system and implement a "best" filesystem, no?

Supponiamo che non ci siano stati compromessi e che i progettisti di file system implementassero un filesystem "migliore", libero da preoccupazioni sui brevetti, e rilasciato come doppia licenza BSD / GPL in modo che fosse accettabile sia per MS che per Debian. Cosa ti fa pensare che gli altri file system svaniranno da un giorno all'altro?

Non credo che nessuno abbia usato FAT32 su un nuovo disco rigido per 10 anni, ma persiste ancora come standard de facto per la formattazione di unità USB, schede SD, ecc. I produttori di fotocamere e telefoni cellulari hanno provato e testato il firmware per usandolo. Gli appassionati di Arduino hanno librerie stabili per usarlo. Avranno tutti bisogno di grandi incentivi per cambiare.

E poi hai i problemi di retrocompatibilità con i vecchi sistemi operativi (specialmente Windows, i cui utenti non vorranno installare nuovi driver per filesystem).

Come spesso accade nel calcolo, la risposta è (a) a causa delle circostanze storiche e della necessità di mantenere la retrocompatibilità e (b) perché alcuni metodi sono più adatti ad alcuni compiti di altri.

On (a) è necessario ricordare che il "drive Winchester" - sono abbastanza vecchio per ricordare che sono stati chiamati così - (ciò che il resto del mondo chiama un "hard disk") è stato solo intorno circa la metà del tempo del calcolo elettronico e anche in quel caso non è stato accessibile alla maggior parte degli utenti nemmeno per lunghi motivi. Il file system FAT ha funzionato bene su floppy disk e anche sui piccoli dischi rigidi originali in quanto era ragionevolmente efficiente e richiedeva un basso overhead. Una volta iniziato a essere utilizzato - e il suo uso si è diffuso ampiamente perché è semplice da implementare - i produttori non potevano dire ai propri utenti che i loro vecchi dati erano improvvisamente non validi.

Allo stesso modo, per gli utenti di Linux, ad esempio, un driver NTFS stabile era in arrivo da molto tempo, quindi mantenere i dispositivi formattati come FAT significava che potevano essere letti e scritti su più sistemi.

On (b) - Pensa alle differenze tra un sistema che, ad esempio, memorizza, miliardi di record di database basati su testo e uno che archivia file multimediali di lunghezza DVD. Per il databse ogni record potrebbe essere molto piccolo - forse solo 30 o 40 byte e certamente un filesystem che ha assegnato un intero 'segmento' (comunque lo si voglia definire) del disco rischia di essere uno spreco di spazio. Non così con i DVD - i "segmenti" più grandi (entro limiti ragionevoli, ovviamente) sono probabilmente molto efficienti in termini di spazio.

Quindi diversi filesystem sono progettati per scopi diversi.

Ancora un altro esempio del perché non possa mai esistere un file system perfetto per tutti: gli HDD e gli SSD hanno caratteristiche di accesso in lettura / scrittura molto diverse. Un filesystem ottimizzato SSD probabilmente funzionerebbe meglio frammentando i file come un matto, ma con ogni frammento le dimensioni della pagina del SSD stesso; questo funzionerebbe terribilmente su un HDD. Un filesystem ottimizzato per l'HDD cerca di mantenere i file il più frammentati possibile e persino di inserire i file utilizzati più frequentemente nell'area "calda" sulla parte esterna del piatto che gira più rapidamente; queste caratteristiche non aiutano affatto le velocità di lettura SSD e mettono un enorme ingombro sul modo in cui sono state scritte.

Penso che manchi un fatto molto importante. Il più delle volte i programmatori tendono a pensare che il loro modo di fare qualcosa sia superiore a tutti gli altri modi e quindi guardano a un progetto di File System e creano problemi e soluzioni che sembrano essere più generali, eleganti, veloci, giuste .. E se questa sensazione è abbastanza strong sono liberi di costruire il proprio file system.

Questo è alleggerito dalla competizione, dalla frammentazione, dalla confusione e spero che alla fine migliori soluzioni e più opzioni per scegliere una soluzione di abbinamento per te.

Ecco un altro esempio concreto del perché avresti bisogno di un file system separato o estendi la funzionalità di un FS esistente.

1. Supponiamo che tu sia un fornitore di database e desideri ridurre la complessità della gestione dello striping / mirroring dei dati per migliorare l'IO. Sentirai la necessità di estendere la funzionalità dei file system di base come Oracle ha fatto con ASM (Automated Storage Manager) che è come un Logical Volume Manager.

Nel tuo elenco menzioni un vecchio filesystem usato perché uno migliore non è disponibile ma è veloce.

Ci sono altri filesystem. Ho sentito che google filesystem è principalmente per la duplicazione / ridondanza veloce in caso di guasto di un disco rigido o di un server. Ricordo di aver sentito un altro file system creato per molti piccoli file e di essere usato su un sistema per molte richieste su file di piccole dimensioni (miniature).

Essenzialmente hanno obiettivi di differenza e possono essere di proprietà o open source.

Penso che ZFS (usato da Solaris nel sistema Sun [ora Oracle]) sia LA soluzione per il file system.

sfortunatamente Oracle chiude OpenSolaris per scoprirlo e testarlo.

ZFS è open source, alcuni Linux stanno cercando di integrarlo, guarda in Wikipedia per maggiori informazioni.