Con molti nuovi dischi rigidi la dimensione del settore fisico è 4096. Sarebbe possibile fare in modo che il sistema utilizzi una dimensione del settore logico della stessa dimensione, anziché la dimensione del settore logico predefinita di 512?
Accelererà la lettura e la scrittura di massa? Dove può essere configurato?
Risposte:
512 byte non corrispondono in realtà alle dimensioni del settore predefinito. Dipende dal tuo hardware.
Puoi visualizzare quale settore fisico / logico dimensiona i rapporti del tuo disco tramite lo /syspseudo filesystem, ad esempio:
# cat /sys/block/sda/queue/physical_block_size
4096
# cat /sys/block/sda/queue/logical_block_size
512
Qual è la differenza tra questi due valori?
physical_block_sizeè la lunghezza minima di un blocco l'unità è in grado di scrivere in un'operazione atomica.logical_block_sizeè la dimensione più piccola l'unità è in grado di scrivere (Cf. la documentazione del kernel linux).Pertanto, se si dispone di un'unità 4k, è logico che lo stack di archiviazione (file system ecc.) Utilizzi qualcosa di uguale o maggiore delle dimensioni del settore fisico.
Tali valori vengono visualizzati anche nelle versioni recenti di fdisk, ad esempio:
# fdisk -l /dev/sda
[..]
Sector size (logical/physical): 512 bytes / 4096 bytes
Sulle attuali distribuzioni di Linux, i programmi (che dovrebbero preoccuparsi della dimensione ottimale del settore) mkfs.xfssceglieranno come impostazione predefinita la dimensione ottimale del settore (es. 4096 byte).
Ma puoi anche specificarlo esplicitamente tramite un'opzione, ad esempio:
# mkfs.xfs -f -s size=4096 /dev/sda
O:
# mkfs.ext4 -F -b 4096 /dev/sda
In ogni caso, la maggior parte delle mkfsvarianti visualizzerà anche la dimensione del blocco utilizzato durante l'esecuzione.
Per un filesystem esistente la dimensione del blocco può essere determinata con un comando come:
# xfs_info /mnt
[..]
meta-data= sectsz=4096
data = bsize=4096
naming =version 2 bsize=4096
log =internal bsize=4096
= sectsz=4096
realtime =none extsz=4096
O:
# tune2fs -l /dev/sda
Block size: 4096
Fragment size: 4096
O:
# btrfs inspect-internal dump-super /dev/sda | grep size
csum_size 4
sys_array_size 97
sectorsize 4096
nodesize 16384
leafsize 16384
stripesize 4096
dev_item.sector_size 4096
Quando si crea il filesystem su una partizione, un'altra cosa da verificare è se l'indirizzo iniziale della partizione è effettivamente allineato alla dimensione del blocco fisico. Ad esempio, guardare l' fdisk -loutput, convertire gli indirizzi iniziali in byte, dividerli per la dimensione del blocco fisico: il promemoria deve essere zero se le partizioni sono allineate.
fdisk -l, diviso per 8 e quindi 512. Il il resto non era 0, quindi la partizione sembra non essere allineata
fdisk -lreport Units = sectors of 1 * 512 = 512 bytesin uno dei miei sistemi Linux - quindi, per un drive logico / fisico 512/4096 con 2 partizioni a partire da 2048 e 1026048 computo 2048*512%4096e 1026048*512%4096- ad esempio in una shell python. Poiché entrambe le espressioni sono uguali a zero, quelle partizioni sono allineate a 4k.
No, non è possibile, né importa se lo fosse. In genere l'IO viene eseguito in unità di almeno 4096 byte e in genere molto di più.
Sì, è possibile, tuttavia ciò potrebbe causare il riempimento dell'unità molto più rapidamente di quanto dovrebbe. Per file inferiori a 512 KB, ogni file occuperebbe quindi 4096 KB (4 MB) e riempirebbe il resto del settore con 0 a causa dell'incapacità della maggior parte dei filesystem (NTFS e simili) di consentire ai file di condividere settori. L'opzione migliore per un filesystem sarebbe quella di consentire dimensioni settoriali variabili, tuttavia ciò aumenta le dimensioni della MFT (tabella dei file master) e aumenta il rischio di corruzione dei dati riducendo al contempo la possibilità di recuperare facilmente i dati. In altre parole, i limiti non sarebbero del tutto noti dal software di recupero. Quindi, mentre una dimensione del settore logico 4096K è eccezionale per file di grandi dimensioni, per un normale PC di uso quotidiano, è solo un gruppo di 0. Ora, detto ciò, vi è la possibilità di memorizzare i dati nella MFT stessa quando si tratta di dati più piccoli della dimensione del settore logico. Questo, tuttavia, significa che la tua MFT diventa enorme e i dati verrebbero scritti due volte (ci sono due copie della MFT sul tuo HDD). Dovresti anche specificare la dimensione massima della MFT che può causare problemi quando si raggiunge il massimo o l'utilizzo dell'unità supera ciò che sarebbe libero per la MFT. Tutto ciò si basa sull'utilizzo di un file system NTFS. Sul lato positivo delle cose, NTFS consente di utilizzare la compressione nativa per i file a livello di blocco per qualsiasi dimensione del settore logico di 4 MB o inferiore. Questa limitazione viene applicata a causa del modo in cui funziona la compressione NTFS. I blocchi da 4 MB vengono letti e compressi indipendentemente dalle dimensioni del settore logico. Questo, ovviamente,
Quindi, questo ti chiarisce un po 'le cose?
Sector:
1) Logical Sector: Called Native Sector.
Manufacture default setting. user cannot change.
Before 2010 year: 512b/sector
After 2010 year: 4k/sector.
Few manufacture provide HDD tool to change native sector.
2) Physical Sector: Called Cluster(or allocation unit - FAT windows) or Block(Linux/Unix)
User can change physical sector size 512b,1k,2k,4k,... by format or partition tool. Physical sector contains one or few more native sectors.
(example1: if you have HDD 512b/native sector: user can set 4K/Physical sector. this mean 1 cluster = 4 native sector)
(example2: if you have HDD 4K/native sector: user can set 4K/Physical sector. this mead 1 cluster = 1 native sector)
3) File system deal with Physical sector(or block or Cluster) only.
mkfs.*dovrebbero utilizzare automaticamente la dimensione ottimale del settore. È possibile eseguire alcunimkfs.*test e ispezionare il risultato (nell'output dettagliato di mkfs o in un programma di utilità fs correlato).