Il file system fa parte del sistema operativo?

Mi chiedevo se un file system su un dispositivo di archiviazione fa parte del sistema operativo?

Non penso lo sia. Invece fa parte del dispositivo di archiviazione ed esiste al di fuori di qualsiasi sistema operativo sebbene sia stato creato da un sistema operativo. La mia comprensione è giusta?

Tuttavia in Wikipedia :

La maggior parte dei sistemi operativi fornisce un file system, in quanto un file system è parte integrante di qualsiasi sistema operativo moderno.

Per LVM, fa parte del sistema operativo? Se sì, allora il filesystem virtuale basato su LVM fa parte del sistema operativo?

Il file system stesso, rappresentato dall'ordine fisico delle informazioni su una rappresentazione di archiviazione, è indipendente dal sistema operativo. Il sistema operativo contiene un driver che gli consente di funzionare con il filesystem. Alcuni filesystem possono avere un solo SO in grado di parlarci, e quel SO ha quel filesystem hardcoded al suo interno (pensa al filesystem originale di Novell NetWare); ma ciò non impedisce a una persona intraprendente di scrivere un tale driver per un altro sistema operativo solo perché.

LVM non è un filesystem, è un gestore di volumi. I gestori di volumi, come i filesystem, si basano sui dati archiviati in una presentazione di archiviazione logica per definire ulteriormente come accedere a tale archiviazione per ulteriori volumi logici. Nel caso di LVM, sia Linux che BSD possono utilizzare lo stesso formato di archiviazione per le rispettive implementazioni LVM.

Il gestore di volumi di Windows è Dynamic Disk e alcune persone intraprendenti hanno creato i driver Linux per accedervi.

Se dovessi prendere una serie di dischi, installare un Linux di qualche tipo, configurarli con LVM, installare diversi ext3filesystem sui volumi logici e quindi posizionare le unità in una macchina FreeBSD, quella macchina FreeBSD sarebbe in grado di leggere i dischi . Probabilmente. Questo perché FreeBSD ha dei driver che comprendono il layout fisico sia di LVM che di ext3 e implementano la memoria interna necessaria e le strutture di accesso necessarie per interagire con essi.

I driver richiesti per interpretare il layout di archiviazione sono quasi sempre "nel sistema operativo", ma il layout di archiviazione vero e proprio non viene considerato.

Ho risposto a questo su ServerFault . Ecco di nuovo la risposta:

Il problema qui è la parola "filesystem". Nei mondi POSIX / Unix / Linux, è usato per significare diverse cose.

1. Il "filesystem" è talvolta l'intero sistema di file, radicato /e presentato alle applicazioni software dal kernel del sistema operativo. Con questo significato, ad esempio, le persone parlano di sistemi operativi POSIX che hanno un "singolo albero di filesystem ".
2. Un "filesystem" è talvolta una (o più) fetta (e) di uno (o più) dispositivi di archiviazione ad accesso diretto o DASD - una o più raccolte di settori del disco contigui formattati come un singolo volume con un formato specificato - come delimitato da alcuni schemi di partizionamento del disco. Con questo significato, la gente parla di, diciamo, "formattazione del /usrfile system ".
3. Un "filesystem" è talvolta un albero unificabile astratto di file e directory, presentato da un driver di filesystem (cioè il livello VFS) al resto del sistema. Con questo significato, la gente parla di, diciamo, "montare il filesystem proc su /proc".

La prosa di Wikipedia significa n. 1. Questo è, in effetti, parte del sistema operativo, in quanto è un sistema operativo fornito, e specifico del sistema operativo, astrazione fornita al software applicativo che gira sul sistema operativo.

Il significato n. 2 non fa parte del sistema operativo. È una struttura di dati su disco che uno o più sistemi operativi sono in grado di comprendere. Le strutture di dati su disco per LVM, in particolare, forniscono modi per suddividere uno o più DASD in uno o più volumi. Non fanno parte del sistema operativo in sé. (Allo stesso modo, "LVM" ha molteplici significati e può indicare i driver e le utilità LVM nel sistema operativo tanto quanto può significare le strutture di dati su disco che tali driver e utilità manipolano. Ad esempio "Ho eseguito LVM dal disco di salvataggio. ")

Significato # 3 è un'astrazione specifica del sistema operativo fornita dai driver di file system specifici del sistema operativo. I driver del filesystem sono, in effetti, parte del sistema operativo, sebbene di solito siano distinti e separati dal kernel del sistema operativo .

Un file system viene creato, gestito e utilizzato da un sistema operativo, ma hai ragione a concludere che la sua rappresentazione può esistere indipendentemente da un sistema operativo.

Non esiste una definizione formale di "sistema operativo". Alcuni erano soliti sostenere che "sistema operativo" e "API di gestione dei file" fossero la stessa cosa, con il sistema operativo che non aveva nient'altro da fare se non fornire un analizzatore di comandi. (Dopo tutto, questo è tutto ciò che ha fatto MS-DOS, in origine.)

Ho sempre sostenuto che DOS non era un vero sistema operativo, che il compito di un sistema operativo era quello di astrarre e virtualizzare l'hardware e gestire le risorse hardware. DOS non ha fatto essenzialmente nulla di tutto ciò.

Se un file system è una parte del sistema operativo o una parte del "dispositivo di archiviazione", molto dipende a sua volta da ciò che si intende per "file system". C'è il layout fisico, come il layout su un floppy disk o un CD, e c'è il file system FUNCTION, che dipende dall'avere qualche entità intelligente (CPU o processore periferico di qualche tipo) per accettare le sciocchezze sul disco e restituire come una sequenza significativa di byte. Il layout presumibilmente è conforme ad alcuni standard, quindi è possibile, ad esempio, registrare un CD su un dispositivo e leggerlo / riprodurlo su un altro. La domanda è se questo layout è un "file system" o se il "sistema" risiede nei dispositivi abbastanza intelligente da leggere / scrivere il layout.

Nella maggior parte dei contesti informatici, si usa il termine "file system" per fare riferimento alle API che consentono di leggere / scrivere file e la combinazione di CPU e periferiche, che operano sotto il controllo di alcuni sistemi operativi, che implementano tali API: il termine di solito non si riferisce al formato fisico dei media, o dei singoli media, rimovibili o meno.

L' implementazione particolare fa parte del sistema operativo. L'idea astratta, le specifiche e i dati memorizzati non lo sono.

Le unità disco e i dispositivi simili a unità disco sono "stupidi". Lo chiedi per un LBA, ti restituisce i 512, 2048 o 4096 byte che contiene; viceversa per la scrittura.

Un livello di filesystem ti permette di dire "Voglio c: \ utenti \ pubblici \ documenti \ whatever.doc" ed eseguire operazioni di streaming su quello (apri, leggi, scrivi, cerca, chiudi) - si traduce da posizioni indirizzabili in una serie di richieste per leggere / scrivere LBA.

Quindi il livello del filesystem ha due lati, uno che comunica con il dispositivo simile a un'unità disco (o blocco) e l'altro che comunica con il sistema operativo. È qui che entra in gioco la specificità del sistema operativo. Di solito il lato dispositivo a blocchi del filesystem è un driver di dispositivo e il lato del sistema operativo è un'API utilizzabile dalle applicazioni. Ma queste sono solo interfacce e non devono davvero influire sul funzionamento sottostante del livello del filesystem.

Tutti i filesystem causano la scrittura e la lettura di dati aggiuntivi al di fuori dei dati dei file, al fine di tenere traccia delle informazioni sui file, ad esempio per registrare autorizzazioni, attributi, ecc.

Vi è un po 'di problemi con l'uovo e la gallina all'avvio: i file del sistema operativo sono archiviati nel filesystem, ma come vengono caricati se il layer del filesystem non è ancora attivo? Linux risolve questo problema con un ram disk iniziale o inserendo il codice del filesystem come parte del kernel. Windows risolve questo problema dando al bootloader di Windows la possibilità di leggere le partizioni FAT e NTFS. I bootloader possono essere stupidi, come la maggior parte dei bootloader BIOS classici che caricano solo LBA 0 e lo eseguono e si aspettano che il codice venga prelevato in seguito, o abbastanza intelligente e con piccoli livelli di file system propri, come UEFI, U-boot, ecc.

LVM non è un filesystem. Prende uno o più dispositivi a blocchi e lo estrae in un altro dispositivo a blocchi "virtuale" (in /dev/mapper- qualsiasi cosa in /dev/mapperè un dispositivo a blocchi virtuale). Metti un filesystem "sopra" un LVM nello stesso modo in cui metti un filesystem "sopra" una partizione. LVM è un altro livello tra uno o più driver di dispositivo e il filesystem, che converte letture e scritture in LBA sul dispositivo a blocchi virtuale in uno o più altri dispositivi a blocchi. Sì, un LVM può essere un dispositivo a blocchi virtuali e puoi avere una cascata di essi.