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.