Re: (deb-cat) Mida de blocs per a RAID de programari
El 23/7/23 a les 10:19, Alex Muntada ha escrit: 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. Estàs pensant només en les operacions de lectura i escriptura, però els raids fan més coses (càlculs d'integritat, redundància, etc.) i potser la mida per defecte del chunk té en compte tot plegat, fins i tot la compatibilitat entre versions (com apunta el man). De totes maneres, la millor forma de veure si un escenari concret millora el rendiment és fer-ne mesures i comparar-les amb unes altres de referència. Si aconsegueixes esbrinar quina és la mida de bloc del capçal d'un disc i obtens millor rendiment, no deixis de compartir-ho amb nosaltres, si et plau. Ho faré. La gran majoria de vegades implemento RAID0, altres RAID1 i combinacions, perquè sempre m'ha decebut el fre dels càlculs. Per tot el què he llegit, dedueixo que cal separar: 1. Els discs rotatius, que tenen les pistes com a separador per al treball físic del capçal. Aquí caldria assumir com a bloc: la pista/cilindre. Indiferent si són òptics, durs, etc. https://en.wikipedia.org/wiki/Cylinder-head-sector Amb això crec que tenien raó els què buscaven l'alineació de les particions abans que es passés de moda. Pot fer falta revisar la correspondència amb l'adreçament LBA. 2. Les unitats sòlides (SSD i USB) en el cas de la tecnologia NAND organitzen les escriptures en blocs de pàgines de dades, que són les causants de la fragmentació física entre sectors lliures i utilitzats. Aquí cal primer esbrinar la mida de la pàgina de dades, i la mida del grup (bloc) de pàgines per a fer-ne un tot com a unitat del tros/chunk per al RAID. https://en.wikipedia.org/wiki/Trim_(computing) Sembla doncs que per a discs rotatius el tema és madur i fàcil, sempre i quan s'alinei la partició i també s'alinei el tros/chunk del RAID amb aquesta. Però caldria trobar alguna comanda que informi de l'arquitectura d'una unitat sòlida, i la seva correspondència amb l'adreçament LBA que fan servir els sistemes operatius. El benefici de tot això, pot ser petit o pot ser gran, però veig molt clar que afecta a la velocitat d'entrada/sortida de TOTES les estructures lògiques. -- 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.
Re: (deb-cat) Mida de blocs per a RAID de programari
Hola, Narcis: > 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 crec que la definió de la viquipèdia sigui restrictiva; parla del cas dels discs durs perquè la pàgina és sobre discs durs. > 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. A les configuracions de preseed del d-i per al raid no he vist que s'hi pugui posar la mida, així que segueixo sense veure cap altra alternativa que no sigui early_command. > 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. Crec recordar que era el partman en mode manual, però fa temps que no ho he provat. > 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. Estàs pensant només en les operacions de lectura i escriptura, però els raids fan més coses (càlculs d'integritat, redundància, etc.) i potser la mida per defecte del chunk té en compte tot plegat, fins i tot la compatibilitat entre versions (com apunta el man). De totes maneres, la millor forma de veure si un escenari concret millora el rendiment és fer-ne mesures i comparar-les amb unes altres de referència. Si aconsegueixes esbrinar quina és la mida de bloc del capçal d'un disc i obtens millor rendiment, no deixis de compartir-ho amb nosaltres, si et plau. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
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
Re: (deb-cat) Mida de blocs per a RAID de programari
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. > 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 > 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. > (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). Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: (deb-cat) Mida de blocs per a RAID de programari
hola (responc entre línies) El 21/7/23 a les 15:52, Alex Muntada ha escrit: Hola, Narcis: Em sorgeixen 2 dubtes: 1. Com esbrinar la mida mínima de bloc que llegeix o escriu un disc dur. «fdisk -l» em diu això: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Així que imagino que la mida mínima/òptima per escriure en aquest disc és 512 bytes. Ara bé, això no vol dir que la mida òptima per al sistema operatiu sigui aquesta, ja que abans d'arribar a la capa física del disc, les dades han de travessar una pila de capes més. 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. 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. És per això que necessito esbrinar la mida de l'operació de disc; perquè el programari ja es pot configurar. 2. Com variar aquesta mida de bloc del RAID amb el DebianInstaller. A la documentació no trobo enlloc que es pugui canviar la mida de bloc (o chunk, com li diu mdadm). He seguit aquest camí: https://wiki.debian.org/DebianInstaller/Preseed https://www.debian.org/releases/stable/amd64/apbs04.en.html https://salsa.debian.org/installer-team/debian-installer/tree/master/doc/devel A l'exemple de preseed tampoc trobo cap referència als blocs o els chunks: https://www.debian.org/releases/bookworm/example-preseed.txt Així que si vols personalitzar el RAID al teu gust, només se m'acut l'opció del `preseed/early_command`, que permet executar el que tu vulguis durant la instal·lació. Però aleshores necessitaràs passar-li a l'instal·lador les opcions de preseed, els scripts que necessitis, els paquets udeb addicionals que calgui, etc. Normalment només és pràctic si fas una instal·lació remota perquè se li han de passar una pila de paràmetres al nucli, que en local els hauràs d'escriure a mà (desconec si es poden llegir d'algun altre lloc). Em convé cal provar si el DebianInstaller preveu una instal·lació dins un RAID que ja estigui creat abans. (per exemple, un volum encriptat no és el cas) Salut, Alex 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.
Re: (deb-cat) Mida de blocs per a RAID de programari
Hola, Narcis: > Em sorgeixen 2 dubtes: > 1. Com esbrinar la mida mínima de bloc que llegeix o escriu un > disc dur. «fdisk -l» em diu això: Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Així que imagino que la mida mínima/òptima per escriure en aquest disc és 512 bytes. Ara bé, això no vol dir que la mida òptima per al sistema operatiu sigui aquesta, ja que abans d'arribar a la capa física del disc, les dades han de travessar una pila de capes més. > 2. Com variar aquesta mida de bloc del RAID amb el > DebianInstaller. A la documentació no trobo enlloc que es pugui canviar la mida de bloc (o chunk, com li diu mdadm). He seguit aquest camí: https://wiki.debian.org/DebianInstaller/Preseed https://www.debian.org/releases/stable/amd64/apbs04.en.html https://salsa.debian.org/installer-team/debian-installer/tree/master/doc/devel A l'exemple de preseed tampoc trobo cap referència als blocs o els chunks: https://www.debian.org/releases/bookworm/example-preseed.txt Així que si vols personalitzar el RAID al teu gust, només se m'acut l'opció del `preseed/early_command`, que permet executar el que tu vulguis durant la instal·lació. Però aleshores necessitaràs passar-li a l'instal·lador les opcions de preseed, els scripts que necessitis, els paquets udeb addicionals que calgui, etc. Normalment només és pràctic si fas una instal·lació remota perquè se li han de passar una pila de paràmetres al nucli, que en local els hauràs d'escriure a mà (desconec si es poden llegir d'algun altre lloc). Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
