Re: (deb-cat) Mida de blocs per a RAID de programari
Hola Àlex, responc entre línies;
El 22/7/23 a les 10:05, Alex Muntada ha escrit:
Hola, Narcis:
Aquesta és la mida de sector, que és de 512 bytes per al 90%
dels mitjans (USB, FDD, HDD, etc.) independentment de quants
bytes escrigui el capçal en una sola operació. La mida de
sector, ni la mida de bloc del sistema de fitxers, no està
vinculades a les operacions físiques.
«The sector is the minimum storage unit of a hard drive.»
https://en.wikipedia.org/wiki/Disk_sector
Entenc doncs que el capçal no escriu bytes sinó sectors.
Des que existeix el IBM PC (PC x86 i també abans) que el mínim que es
demana a llegir directament de disc és 1 sector. Però això no és una
limitació per al capçal, que des de bon principi ja podien operar per
exemple amb «sectors llargs», i jo he vist des de la dècada de 1990 BIOS
a les quals se'ls pot demanar que el disc dur allargui els
trossos/chunks de lectura i escriptura per augmentar la velocitat
seqüencial. No recordo bé si podien ser de 1 MiB o com s'expressa
aquesta configuració.
La frase de la Wikipedia té una falla: La definició de sector no està
restringida a discs durs, ni mai no ho ha estat.
No busco la mida òptima per al sistema operatiu, sinó l'òptima
per al dispositiu físic. És a dir, que si el capçal d'un disc
dur escriu com a mínim 2048 KiB, aleshores seria molt ineficient
establir blocs/chunks de 512 KiB a la capra RAID, perquè el
sistema operatiu podria demanar escriure 4 vegades el mateix
segment de disc per a emplenar-lo de dades independents de
512 KiB cada tros/chunk.
No hi ha cap menció a la mida del que escriu el capçal en aquest
article; en canvi hi ha molts d'altres factors que afecten el
rendiment físic d'un disc (tot i que els fabricants no donen pas
tots aquests detalls normalment):
https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics
Suposo els factors més proper de l'article és el «interleave».
Abans d'això suggereix que el capçal llegeix tota una pista sense pausa
de canvi.
Fixa't que l'article s'acosta més al tema de l'eficiència de la lectura
i escriptura quan parla de la fragmentació en unitats sòlides (SSD),
perquè els trossos/chunks de dades sovint són més grans que els blocs
que envia el sistema operatiu.
Em convé cal provar si el DebianInstaller preveu una
instal·lació dins un RAID que ja estigui creat abans.
A la meva anterior feina ho fèiem per a tots els servidors
(físics i virtuals), amb mdadm/lvm, etc. segons ens convenia
en cada cas. No va ser trivial arribar a un escenari que ens
funcionés perquè hi havia poca documentació sobre el tema,
però amb el temps van aconseguir tenir totes les instal·lacions
de servidors automatitzades i amb particionat a mida.
Val a dir que, en aquell escenari, utilitzàvem Foreman i Puppet
per a fer la instal·lació remota i la personalització dels scripts
de cada cas a partir de variables. Imagino que s'hauria de poder
fer quelcom similar carregant els scripts d'algun disc USB o
similar per simplificar-ho una mica.
Tinc prevista la instal·lació amb un programet (script) prescindint de
DebianInstaller, però el què ara estic explorant és 1 sola
personalització per a seguir amb DebianInstaller quan no vull complicar
res més.
(per exemple, un volum encriptat no és el cas)
Imagino que també podries fer-ho si li pots passar la contrasenya
al DebianInstaller per muntar el disc abans de procedir amb la
resta de passes del early_command. De fet, el particionador et
detecta normalment el que ja tens quan fas particionat manual
(fins i tot et pregunta la contrasenya dels discs xifrats).
Cap versió de DebianInstaller no m'ha preguntat mai pel desbloqueig d'un
volum LUKS; sempre he hagut d'eliminar-lo i crar-lo de nou.
La meva idea és fer servir el mitjà .ISO que publica Debian, sense
modificar-lo, amb el seu DebianInstaller.
El què no he provat encara sobre això és a desbloquejar un volum LUKS
amb un TTY diferent abans que s'obri l'assistent per a Parted.
A on vull anar a parar amb tot això és a, si resulta que un capçal
llegeix i escriu, per exemple, 4 MiB a cada demanda, és molt ineficient
establir trossos/chunks de RAID de 512 KiB, ja que el sistema operatiu
demanarà 8 vegades la mateixa operació al capçal per a llegir o escriure
cada subdivisió dels 4 MiB.
Aleshores m'interessa establir la mida del tros/chunk dels RAIDs COM A
MÍNIM de la mida d'allò que opera el capçal. Amb això el RAID
maximitzaria la velocitat per a fitxers d'una mida major.
El segon article que citaves ja parla de què els SSD operen amb trossos
d'entre 256 KiB i 4 MiB. Pel què diu, fins i tot si es fessin coincidir
els blocs del sistema de fitxers del sistema operatiu amb els trossos
físics d'un SSD d'ús típic, no caldria trim/discard per a mantenir la
velocitat que dóna prestigi al SSD.
Gràcies.
--
Narcis Garcia
__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
Reply to: