Já před vytvářením nového fs spíš volám blkdiscard, takže tohle jsem ani moc nezaznamenal.
Prakticky spíš vnímám rozdíly, když dělám na některých oddílech off-line fstrim. Třeba u Btrfs se snapshoty je to občas docela brutál a fakt na hodně dlouho i když to není nějak extra obrovský oddíl (512GB SSD).
Tak jsem to ted zkousel na jednom ssd (samsung 860evo 1tb, sata):
# time blkdiscard /dev/sdl -v /dev/sdl: Discarded 1000204886016 bytes from the offset 0 real 0m10.130s user 0m0.000s sys 0m0.132s
A dalsi behy
real 0m9.891s user 0m0.002s sys 0m0.123s real 0m9.961s user 0m0.000s sys 0m0.128s real 0m11.061s user 0m0.000s sys 0m0.130s real 0m10.073s user 0m0.000s sys 0m0.132s
Proste to trva stejne a relativne dlouho i kdyz to bylo discardnuty pred chvili. A ne, nezmeni to ani vetsi prodleva, porad je to 10-11 sec. Myslim ze stejne se chovali samsung sas ssd, jen jeste pomalejic u toho mkfs, ten pise takovej progress kdyz discarduje.
Bez zaplnění a uvolnění těžko říct,.co to přesně znamená:
a. SSDčku je jedno, co již bylo trimnuté.
b. Je tam spousta již vytrimovaného místa, ale těch cca 10s je potřeba na projití. Kdyby bylo co trimovat, trvalo by to ještě déle.
BTW, Další věc je situace, kdy TRIM je bleskový. Technicky vzato to nemusí znamenat, že se celý proces povedl tak rychle, stačí, když controller uvolní příslušné paměťové bloky a jejich výmaz provede na pozadí. (Samozřejmě musí s tím počítat, do vymazání nemůže do těchto bloků zapisovat.)
Spíš bych tomu říkal oprava chyby.
Když je na disku 80GB blok který je potřeba discardnout a driver to vždy dělá po mrňavých kouskách, to mi připadá spíš jako chyba a skoro průšvih který asi dost zatěžuje to SSD nebo microSD, než jen neoptimální disková operace.
Pokud si vzpomínám, tak moje úplně plná 256GB microSD potřebovala na blkdiscard celého média poprvé snad půl minuty, ale když jsem vzápětí udělal podruhé totéž tak to samozřejmě bylo za vteřinu nebo dvě. Naopak discard na M.2 SSD byl vždy hned. Discard není vždy stejný, na 80 GB to asi nebude vždy ta vteřina a půl, může to být desetina vteřiny a jindy desítky vteřin. Ale pořád lepší jeden velký blok než každý cluster zvlášť, to zas jo, to považuju za dost důležité.
a jak jinak to chceš dělat než po kouskách (=clusterech), když právě na těch kouskách je založena celá architektura exfatu?
A jaký fs jsi měl na tom ssd? Byl to exfat? Velikost clusteru (a tedy i jejich počet) se volí při formátování fs podle velikosti oddílu, běžně je cca 128 KB pro oddíly v desítkách GB.
Díky. Vzpomněl jsem si - bylo to jinak. Nešlo o starší flešku, ale celkem nové 256GB NVMe v USB3 adaptéru. Byl na ní ext4 (vytvořeno na linuxu) a pro připojení k win samozřejmě bylo potřeba přejít na něco jiného. Zazálohoval jsem data (několik málo GB za chviličku) na lin PC, přeformátoval na vfat a kopírování dat zpět trvalo půl hodiny. Takže to nemělo s discardem nic společného, sorry. Nicméně i tak by mě zajímalo, proč to jelo tak pomalu (v lsusb -t zkontrolováno, že připojeno přes USB3 5Gbps).
2. 4. 2025, 09:18 editováno autorem komentáře
Na problém SSD v USB adaptéru jsem narazil na RPi (mj. se disk odpojoval).
Podívejte se do logu, jestli tam nejsou chyby - problém byl v uas driveru, po zapnutí quirk mode pro dané zařízení to začalo fungovat spolehlivě.
Popsáno zde:
https://forums.raspberrypi.com/viewtopic.php?f=28&t=245931
Někde jinde psali, že na to narazili u Dellu a pod., asi to není problém RPi, ale uas driveru a některých (debilních) čipů na převodníku.
Díky moc. Do dmesg jsem tehdy koukal, nic tam nebylo. Byl to tenhle box https://www.alza.cz/axagon-eem2-gtr-m-2-nvme-thin-rib-box-superspeed-usb-c-10-gbps-black-d6803546.htm
Jo, ten UASP quirk mě napadl taky, nicméně pokud to ještě máte, tak bych se asi snažil nějak postupně vylučovat případné problémy s pomalými zápisy.
Pokud to jde, tak bych zkusil vykopírovat užitečná data a otestoval např.
- normální zápis souborů na čerstvý filesystém vs. přímo do blok. zařízení (fio, dd).
- udělat blkdiscard, případně pro zajímavost i erase příkaz. I když tam je to trochu komplikovanější, protože nevím, jak se konkrétní převodník chová. U nativního NVMe zařízení na PCIe jde použít nvme-cli (nvme format, resp. nvme sanitize), u SAS/SATA zařízení to pak jde většinou udělat pomocí hdparm, viz. https://grok.lsu.edu/article.aspx?articleid=16716, resp. sg_sanitize z sg3_utils.
Tím, že tohle je NVMe zařízení ve škatuli, co z toho dělá SCSI over USB, netuším, jestli ten řadič přemapuje i tyhle příkazy.
- zmíněný quirk