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

Solo una domanda veloce, ma perché ci sono così tanti file system ancora in competizione e in uso oggi? (ntfs, fat32, ext3 (ffs), ecc.)

Sembra che i progettisti di file system potrebbero concordare i migliori aspetti di ogni tipo di sistema e implementare un "migliore" filesystem, no? Solo un pensiero, dal momento che questi filesystem sono in circolazione da un po 'di tempo, e dovrebbe essere almeno un po' evidente quali hanno delle buone qualità rispetto agli altri, e potremmo semplicemente combinare il buono in ciascuno e creare un sistema finale che è molto meglio

Pensiamo alle specifiche qui per un momento, usando 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 usarlo su FAT a causa dei problemi del prossimo punto elenco.

• fat32 - Non sufficientemente moderno. La dimensione massima del file è di 4 GB. La ricerca della voce di directory è O (n). La tabella di allocazione è un elenco collegato, piuttosto che qualcosa di più efficiente come una bitmap di allocazione (dove è davvero veloce trovare spazio libero contiguo). Non supporta le autorizzazioni. Non supporta collegamenti reali o collegamenti simbolici. Non supporta l'inserimento nel journal.

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

Quindi, sembra che ci siano alcuni motivi:

1. Un file system precedente manca di qualcosa. Nel caso di FAT manca molto: sia in termini di (1) caratteristiche che (2) prestazioni. Nel caso di ext2 non aveva aggiornamenti di journaling, quindi il recupero da un crash ha richiesto più tempo.

2. Un filesystem esistente probabilmente lo farebbe, ma non è tuo. (es. NTFS se non sei Microsoft). In questo caso, non hai molta scelta ma inventare la tua.

Risposta breve: una taglia non va bene per tutti.

Ci sono compromessi. Ad esempio, se si desidera un FS registrato su giornale, si paga (efficienza, complessità, ecc.) Per esso, ma si ottiene qualcosa da esso. Alcuni non sentono il bisogno di un diario di bordo e non vogliono pagarlo, altri lo fanno. Lo stesso con altre "caratteristiche" di FS.

Non può mai esserci un "migliore" di niente perché ci sono così tante opinioni su cosa sia il "migliore". La decisione è specifica per le esigenze e le limitazioni dell'utente. I progetti si basano sempre sulla loro capacità di adattarsi ai vincoli.

Un telefono cellulare di base deve archiviare 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? Esiste RAM sufficiente sul dispositivo per eseguire un tale filesystem? Il filesystem necessita di ACL complessi? Probabilmente no - per tutte queste domande - sarebbe sufficiente un semplice filesystem che sorseggi risorse.

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

Troppo dipende da ciò che si desidera ottimizzare.

Prendi in considerazione il FAT per un momento: il suo supporto per nomi di file lunghi è kludgy (per dirla bene) e la ricerca tra i file in una directory è lineare, quindi diventa molto lenta se una directory contiene molti file. Allo stesso tempo, ha un minimo di metadati per una velocità di scrittura non elaborata molto buona e, dato che è molto semplice, il codice da implementare può essere piuttosto piccolo.

Qualcosa come ext2 o ext3 aggiunge molte caratteristiche e capacità che sono semplicemente assenti da FAT. La ricerca di file è anche 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 è senza dubbio molto più grande.

Solo una domanda veloce, ma perché ci sono così tanti file system ancora in competizione e in uso oggi? (ntfs, fat32, ext3 (ffs), ecc.)

Sembra che i progettisti di file system potrebbero concordare i migliori aspetti di ogni tipo di sistema e implementare un "migliore" filesystem, no?

Supponiamo che non ci siano compromessi e che i progettisti di file system abbiano implementato un "migliore" filesystem, privo di preoccupazioni sui brevetti, e rilasciato come doppia licenza BSD / GPL in modo che sia accettabile sia per MS che per Debian. Cosa ti fa pensare che gli altri file system svaniranno dall'oggi al domani?

Non credo che nessuno abbia usato FAT32 su un nuovo disco rigido per 10 anni, ma persiste ancora come standard di fatto per la formattazione di unità USB, schede SD, ecc. I produttori di fotocamere e telefoni cellulari hanno provato e testato il firmware per usarlo. 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 di file system).

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 rispetto ad altri.

Su (a) devi ricordare che il "disco Winchester" - io sono abbastanza grande da ricordare che si chiamano così - (quello che il resto del mondo chiama un "disco rigido") è in circolazione da circa la metà tempo di elaborazione elettronica e anche in questo caso non è stato accessibile alla maggior parte degli utenti nemmeno per così tanto tempo per motivi di costo. Il file system FAT ha funzionato bene su floppy disk e anche su piccoli dischi rigidi originali in quanto era ragionevolmente efficiente e richiedeva un basso sovraccarico. Una volta che ha iniziato a essere utilizzato - e il suo utilizzo si è diffuso ampiamente perché è semplice da implementare - i produttori non sono stati in grado di dire ai propri utenti che i loro vecchi dati erano improvvisamente non validi.

Allo stesso modo, per gli utenti Linux, diciamo, un driver NTFS stabile è arrivato 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, per esempio, memorizza, miliardi di record di database basati su testo e uno che memorizza 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 allocato un intero "segmento" (comunque lo si desideri definire) del disco rischia di sprecare spazio su disco. 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.

Un altro esempio del perché non può mai esistere un file system perfetto per tutti: HDD e SSD hanno caratteristiche di accesso in lettura / scrittura molto diverse. Un filesystem ottimizzato per SSD probabilmente funzionerebbe meglio frammentando i file come un matto ma con ogni frammento la dimensione della pagina dell'SSD stesso; ciò si comporterebbe terribilmente su un HDD. Un filesystem ottimizzato per HDD cerca di mantenere i file il più frammentati possibile e mette persino i file usati di frequente nell'area "calda" sulla parte esterna del piatto a rotazione più veloce; queste caratteristiche non aiuterebbero affatto la velocità di lettura dell'SSD e mettono un enorme ingombro sul modo in cui sono 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 presentano problemi e soluzioni che sembrano essere più generali, eleganti, veloci, giuste ... E se questa sensazione è abbastanza forte, sono liberi di creare il proprio file system.

Ciò favorisce la concorrenza, la frammentazione, la confusione e spero alla fine soluzioni migliori e più opzioni per scegliere una soluzione adatta a te.

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

1. Supponiamo che tu sia un fornitore di database e che 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.

Nella tua lista menzioni un vecchio filesystem usato perché uno migliore non è disponibile ma è veloce.

Esistono altri filesystem. Ho sentito che il filesystem di Google è principalmente per la duplicazione / ridondanza rapida se un hard disk o un server si guastano. Ricordo di aver sentito parlare di un altro filesystem creato per molti piccoli file e di essere usato su un sistema per molte richieste su piccoli file (miniature).

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

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

Purtroppo Oracle ha chiuso OpenSolaris per lo scopritore e lo ha testato.

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