Un file system "vede" il dispositivo di archiviazione come un array di byte (molto grande)?

Voglio sapere come fa un file system a scrivere e leggere da un dispositivo di archiviazione.

Penso che sia così che funziona:

Un file system non accede direttamente al dispositivo di archiviazione, ma piuttosto il dispositivo di archiviazione viene presentato (dal driver del dispositivo di archiviazione) al file system come un array di byte (molto grande).

Ad esempio, se il file system desidera accedere a un disco rigido, accederà semplicemente all'array di byte che rappresenta il disco rigido.

In questo modo un file system può funzionare con qualsiasi tipo di dispositivo di archiviazione (disco rigido tradizionale, SSD, unità flash USB, ecc.) E viene modificato solo il driver di dispositivo per il dispositivo di archiviazione.

Questa immagine mostra ciò che ho appena spiegato:

Sono corretto nella mia comprensione?

Su Linux (e Unixes degli anni '80), un dispositivo di archiviazione (abbastanza spesso una partizione del disco su alcuni dischi rigidi o su alcuni SSD ) è un dispositivo a blocchi (vedi questo ) così è una [sub-] sequenza di blocchi (che è il unità base di I / O fisico ). La dimensione del blocco fisico dipende dall'hardware (i vecchi dischi IDE avevano una dimensione del blocco di 512 byte, i nuovi dischi SATA di grandi dimensioni hanno una dimensione del blocco di 4Kbyte, leggi il formato avanzato di wiki) e quando crei un file system (ad esempio mkfs, vedi mke2fs (8)) puoi specificare una dimensione del blocco logico che è un multiplo (spesso una piccola potenza di due, incluso 1) di quella dimensione del blocco fisico. Leggi anche sull'indirizzamento dei blocchi logici .

In passato (si pensi alle workstation Sun3 degli anni '90) il disco era costituito da cilindri con testate organizzate in settori (leggi CHS wikipage), con un settore contenente un blocco. Oggi, questi rimangono ancora, ma sono un artefatto artificiale fornito dal controller del disco rigido (il circuito sul disco stesso). In alcuni sistemi operativi il driver del dispositivo a blocchi ha riprogrammato e riordinato le richieste IO per ridurre al minimo il movimento della testina del disco e la latenza di rotazione .

In questo modo un file system può funzionare con qualsiasi tipo di dispositivo di archiviazione (disco rigido tradizionale, SSD, unità flash USB, ecc.) E viene modificato solo il driver di dispositivo per il dispositivo di archiviazione.

Sì, ma il male sta nei dettagli (ad esempio leggi su TRIM e Scrivi Amplificazione , specifico per gli SSD). E i dettagli sono importanti, quindi l'implementazione effettiva è meno semplice della tua figura. Leggi di più sui file system (e pensa ai file system cluster e remoti tra cui SMB e NFS ; leggi anche su Logical Volume Manager ).

Leggi i sistemi operativi: tre pezzi facili (e la sua parte di persistenza ).

Nota che i dispositivi a blocchi sono spariti in FreeBSD (fornendo effettivamente un'astrazione comune per i dispositivi a caratteri e blocchi). Sospetto che anche su Windows il sistema operativo sia a conoscenza di partizioni, dimensioni dei blocchi, ecc. (Ma dovresti controllare).

Tutto ciò che Basile Starynkevitch dice è corretto. Aggiungerò un po 'di più. In effetti, le unità disco erano unità "a blocchi", ma i dispositivi a blocchi (e molti altri dispositivi) venivano presentati in due forme: "grezzo" e "cotto". I dispositivi grezzi potevano essere indirizzati solo in blocchi che erano multipli della dimensione del blocco di archiviazione nativo. Quindi un dispositivo a disco grezzo può essere letto o scritto solo uno o più blocchi alla volta, non solo un byte o due. I dispositivi cotti hanno aggiunto uno strato che consentirebbe operazioni così più piccole, così come varie altre funzionalità.

I file system funzionavano con dispositivi non elaborati e quindi li vedevano non come un grande array di byte, ma piuttosto come un grande array di blocchi, come spiegato da BS.