Block size/erase size la SSD e cam 128k (vezi mai sus MIN-IO/OPC-IO) si de mult cam orice folsesti pentru a partitiona un disk a inceput sa alinieze la 1MB, special ca sa nu apara probleme de write-amplification. Din ce m-am uitat nici xfs nici ext4 nu suporta block size peste 64k, btrfs vrea blocksize=pagesize, nu prea ai cum sa optimizezi in directia asta. Aici conteaza si : - ce FS o sa fie pe SSD - ce content o sa fie pe SSD ( multe fisiere mici, sau putine fisiere mari, db, etc) - ce fel de IO o sa fie, intensiv random, secvential, etc,etc. Sunt FS-uri care poti fi mai potrivite pentru un SSD (daca ai un dumb SSD, fara cache) ca de ex. F2FS sau NILFS2 care au conceptul de segmente care incearca sa evide write-amplification. Trebuie sa tii totusi cont de faptul ca un SSD nu e chior, are un controller, are memorie, si o sa atenueze mult din ce incearca un FS sa "strice" asa ca in practica poti sa scapi cu multe.
Nu in ultimul rand: https://www.phoronix.com/review/linux-58-filesystems/2 HTH On Mon, 21 Nov 2022 at 21:09, Adrian Sevcenco <adrian.sevce...@cern.ch> wrote: > Salutare! Am o dilema existentiala legata de un nvme care arata asa: > > NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE > RA WSAME > nvme0n1 0 131072 131072 32768 4096 0 none 1023 > 256 0B > > dupa ureche as tinde sa gandesc ca ce raporteaza ca physical sector e > page-ul ca doar e physical .. > dar imi pare cam mare la 32k.. > > asadar dilema e: formatez cu fs block size de 4k sau de 32k? > > Are cineva un sfat, idee , opinie? > Multumesc frumos! > Adrian > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
