SSD, Cancella dimensione blocco e LVM: PV su dispositivo non elaborato, Allineamento

Voglio installare un nuovo SSD e utilizzare l'intero dispositivo come PV per LVM - in altre parole: non ho intenzione di mettere nemmeno una partizione su questo dispositivo. Pertanto non è necessario allineare le partizioni sui blocchi di cancellazione.

Domande)

È sufficiente impostare --dataalignmentla dimensione del blocco di cancellazione durante l' pvcreateing e --physicalextentsizesu un multiplo della dimensione del blocco di cancellazione durante l' vgcreateing?

Quindi, supponendo che il mio SSD abbia una dimensione di blocco di cancellazione di 1024k, va bene

• pvcreate --dataalignment 1024k /dev/ssd
• vgcreate --physicalextentsize $(( x * 1024 ))k ...

Qualcos'altro da prendere in considerazione?

Supponendo di mettere i filesystem ext4 sui LV in questo VG, sarebbe una buona idea allineare le estensioni ext4 alla dimensione LVM-PE, giusto? Quindi ext4-extents dovrebbe avere le stesse dimensioni o un multiplo di LVM-PE-size?

Grazie per qualsiasi chiarimento!

Sì, ho anche verificato tutto il layout su disco di MBR / PBR / GPT / MD / LVM e sono giunto alla stessa conclusione.

Nel tuo caso (LVM su disco non elaborato), se LVM-PE (estensione fisica) è allineata a 1 MB con pvcreate, puoi essere sicuro che tutte le ulteriori allocazioni dei dati saranno allineate, purché mantieni le dimensioni di allocazione a (1 MB * N) .

Poiché sia ​​"vgcreate -s" che "lvcreate -L" gestiscono le dimensioni senza unità come valore MB per impostazione predefinita, probabilmente non è necessario preoccuparsi molto dell'allineamento dopo aver eseguito correttamente pvcreate. Assicurati solo di non dare la dimensione in% / PE (per lvcreate -l) e B (byte) / S (512B - il settore è sempre 512B in LVM) / K (KB) (per vgcreate -s e lvcreate -L).

=== aggiunto per chiarimenti ===

Proprio come un follow-up, mentre un SSD può avere 1024 KB di dimensioni del blocco di cancellazione come un intero dispositivo, ciascuna dimensione del blocco di cancellazione del flash flash interno / dimensione della pagina rw è probabilmente di circa 32 KB-128 KB / 512B-8 KB.

Sebbene ciò dipenda dal controller di ciascun SSD, la penalità I / O dovuta al ciclo extra di lettura-modifica-scrittura probabilmente non accadrà fintanto che manterrai la tua scrittura allineata per cancellare la dimensione del blocco di ciascun chip interno, che è 32 KB-128 KB sopra esempio. È solo che vuoi che la richiesta di scrittura singola sia abbastanza grande (= cancella la dimensione del blocco di SSD come un intero dispositivo), quindi puoi aspettarti prestazioni migliori guidando in modo efficiente tutti i chip / canali interni.

La mia comprensione è che l'allineamento di 1024 KB è solo una misura di sicurezza, poiché la funzione del chip del controller varia da un fornitore e le specifiche del chip flash cambiano rapidamente. È più importante disporre di una richiesta di scrittura a livello di sistema operativo da eseguire in un pacchetto di grandi dimensioni (1024 KB, in questo caso).

Ora, detto questo, fare mkfs (8) su un blocco LVM allineato a 1 MB interromperà quasi sicuramente l'allineamento di 1 MB per dati / metadati a livello di filesystem. La maggior parte dei filesystem si preoccupa solo di eseguire l'allineamento 4KB, quindi probabilmente non è perfetto per gli SSD (ma, IIRC, i recenti fs come btrfs cercano di mantenere 64 KB + allineamento durante l'allocazione del blocco contiguo interno). Ma molte fs hanno una funzione per raggruppare le scritture (es: configurazione a strisce) per ottenere prestazioni dal RAID, in modo che possano essere usate per fare richieste di scrittura su SSD quasi ottimali.

Voglio davvero appoggiare la mia affermazione con i dati effettivi, ma è stato davvero difficile dimostrare che il controller SSD di oggi è così intelligente e non mostrerà molta degradazione delle prestazioni una volta che sia la dimensione di allineamento che la dimensione di scrittura sono "abbastanza grandi". Assicurati solo che non sia mal allineato (evita <alligamento 4KB a tutti i costi) e non troppo piccolo (1024 KB è abbastanza grande).

Inoltre, se ti interessa davvero la penalità IO, ricontrolla disabilitando la cache del dispositivo e il benchmarking con il test di lettura-scrittura-riscrittura sincronizzato.

A mio avviso, le impostazioni predefinite sono già abbastanza buone. Non penso che devi preoccuparti dell'opzione --dataalignment poiché LVM proverà automaticamente ad allineare tutto in base ai valori esportati dal sysfs, vedi l'opzione "data_alignment_detection" in lvm.conf:

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

Inoltre, non è necessario specificare un Physicalextentsize per vgcreate poiché il valore predefinito è già 4 MB.