Dotaz: Praktický průkaz non-SMR HDD

[PetebLazar]

Jde navrhnout nějaký jednoduchý test (případně již existuje), který prakticky ověří nepoužívání SMR záznamu u konkrétního HDD?

Odpovědi

[NN]

Uz zase? Dej s tim uz pokoj.

[PetebLazar]

Bohužel důvěryhodný seznam non-SMR disků neexistuje. Vyšší velikost cache asi také již jako pravidlo k jejich určení neplatí. Tak bych raději koupil vzorek disku, ten ověřil relevantními testy a v případě očekávaného chování dokoupil dalších N stejných do pole. Asi je možné jít cestou enterprise HDD, kde u nižších kapacit to bude nejspíš OK, ale úspora rozdílu ceny při N discích již není zanedbatelná. Má chyba, pokud tak jsem měl pokračovat ve starém vlákně.

[Petr Tomášek]

IMHO se tu tazatel neptá na seznam disků s/bez SMR, ale na metodu, jak spolehlivě zjistit, zda-li se jedná o SMR či nikoliv (případně nejlépe na utilitku, která to dokáže zjistit).

[NN]

Fajn. Tak ja odpovim. Nijak, smula. Co je na tom tezkeho pochopit? Co je tezkeho pochopit, ze to neudava ani vyrobce a ani specifikace. Tazatel si ma koupit serverove SSD = problem vyresen.

[Petr Tomášek]

Tak si běž koupit SSD a neotravuj tady.

Jestliže tam ten efekt je, pak se to dá i změřit/zjistit, a proč si nedat tu práci a nevymyslet způsob, jak tohle otestovat.

Na testování fake čínských USB-sticků s fakticky nižší kapacitou než inzerují taky existují nástroje na odhalení, tak proč by nemohl být takový nástroj (nebo alespoň postup za použití jiných nástrojů) pro odhalení šindelových HDD...

[Superklokan]

SMR disk by mal mat velmi malu rychlost nahodneho zapisu malych suborov.

Testoval by som to zaplnenim disku na 90-95% a potom zahul. Mal by si vidiet dramaticky prepad vykonu po zaplneni cache.

[PetebLazar]

Můj usecase je dočasný velký soubor(y) o velikosti řádu TB (uncompressed/loseless výstup z NLE pro následný reencoding do H.264/HEVC).

Při exportu reálnou rychlostí je to při 4K24p až 800MB/s (při 4K60p až 2GB/s). Rád bych docílil maximální RD/WR průchodnosti bez překvapivých propadů.

V současnosti zvažuji dvě varianty (pro cílovou kapacitu v řádu 8TB) buď RAID0(4x 2TB HDD 7200 1/min), nebo RAID0 (4x 2TB SSD 2,5") poměr ceny/GB je cca 1:2.

HDD non-SMR 2TB (Seagate 7E2, Ultrastar DC310, ???)

+ asi předvídatelný průběh rychlosti R/W klesající s ubývajícím počtem sektorů/track

+ cena/TB

- asi nezvládne poskytovat části souboru pro paralelní encoding (optimalizace kvality/výkonu encodingu).

- hlučnost/spotřeba

+/- životnost

+/- spolehlivost

SSD 2TB (TLC Crucial MX500?)

+ dobra rychlost čtení (možnost paralelního encodingu NLE souboru po částech + jejich následný merge bez rencodingu)

+ hlučnost/spotřeba

- vyšší cena/TB

+/- propad při trvalém zápisu k ~300MB/s (bez TRIMu méně?) .. stále více než HDD

? TRIM v RAID0

? životnost

+/- spolehlivost

[Max]

Crucial MX500 není vhodné SSD pro neustálé přepisování, je to prostě jen velmi dobrý consumer SSD. 2TB verze má ve specifikaci 700TBW, což při 5 leté záruce odpovídá cca 392GB/den (tj. cca 0.2 DWPD). Takže buď koupit vhodnější SSD (o dost dražší), nebo nejít do SSD a postavit si pole ze SATA disků.
Zdar Max

[PetebLazar]

Cílení zmíněného SSD jsem si vědom. Nemyslim si, ze by docházelo k úplnému přepisu SSD častěji než 1x/tyden. Je to pro finalní encoding projektu. Ty průběžné si mohou kvalitativně vystačit s interním encoderem NLE (v Linuxu bohužel jen NVENC). Jejich datové toky a objemy při renderingu (x0Mbps a xxGB) nepředstavují žádnou výkonostní/objemovou výzvu ani pro HDD.

P.S. Teď jsem zaznamenal dostupnost Crucial MP510 1920GB s celkem těžko uvěřitelnou životností (3120TBW). Již delší dobu využívám MP510 960GB, tak možná půjdu NVMe cestou (nakonec storage jde vždy prodloužit s další byť pomalejší). https://www.alza.cz/corsair-force-series-mp510-1920gb-d5654356.htm?o=3

OT: Taková zajímavost. CEO Blackmagic Design v předmluvě Refereční příručky Davinci Resolve 16 zdraví uživatele v prostředí Mac, Linuxu a Windows (v tomto pořadí). Časy se asi opravdu mění.

[Petr Tomášek]

Nějaký konkrétní postup?

[filip]

Asi jedine prepisovat disk vice nez jednou dokola a sledovat rychlosti. U SMR tam bude propad po naplneni disku (neumi zapsat jen sektor, ale vzdy po vetsich castech). No a pokud propad nebude, tak je disk na planovane pouziti OK.

[LTE]

Mám za to, že se pro SMR disky používají optimalizované SCSI a ATA příkazy ZBC/ZAC (zbc_open, zbc_get_device_info,zbc_report_zones...) Pokud systém detekuje, že se jedná o SMR disk, tak by teoreticky měl nastavit:

/sys/block/*disk*/queue/zoned

na hodnotu jinou než none: The possible values indicated by zoned are "none" for regular block devices and "host-aware" or "host-managed" for zoned block devices.

Další možnost je pomocí nějakého nástroje zkusit použít nějaké ty příkazy, např. zbc_report_zones přes sg3_utils.

Bohužel nemám jak prakticky otestovat, protože SMR disky nemám, ale klasické disky mi v obou případech vrací none.

[qqqhhh]

ZBC/ZAC podporuju iba Host-Aware a Host-Managed (HM-SMR) disky , Drive managed nie

[Petr Tomášek]

Hm, škoda, že jsou HM-SMR tak drahé :-/

Předpokládám, že podpora pod Linuxem nebude až tak špatná...

[qqqhhh]

ja to testujem nahodnymi zapismi po celom disku o velkosti 1MB, po zapisani cca 20gb rychlost a latencia zapisov klesne na katastrofalne hodnoty. spravil som na to maly skript v pythone len teraz sa neviem dostat k zdrojaku.

Seagate je v tomto najhorsi, pouziva SMR u vecsiny novych diskov. Rozoznat sa to da podla 256MB cache. Tipujem ze NAS disky niesu SMR, preto su drahsie.

[PetebLazar]

Lze to chápat tak, že těch zminěných 20GB zápisů zaplní dostupné cache zóny (do nich se zapisuje non-SMR zápisem?) a po jejich zaplnění musí disk upřednostit jejich vypráznění (zápis těchto dat již SMR zápisem na cílovou pozici) a tudíž uspokojování přicházejících dalších požadavků má díky menší prioritě velké latence. Podobný syndrom jako zaplnění SLC-cache u SSD, jen vše s řádově horšími latencemi?

[qqqhhh]

ano presne tak, po zaplneni 20gb konvencnej zony uz nieje kam inde ukladat data preto sa musi cakat na vyprazdnenie do SMR zon. Nenazyval by som to cache , je to skor persistent random-write buffer.

[PetebLazar]

Takže u SMR i při modifikaci jediného sektoru (alokačního bloku), musejí být "přeloženy tašky" (přepsány sektory) všech souvislých šindelových tracků až k nejbližšímu non-SMR tracku)? Aspoň tak si představuji princip a předpokládám, že SMR tracků pro zvýšení efektivity může vedle sebe následovat více (jinak by se výsledná hustota záznamu si moc nezvýšila a zbyla jen režie navíc). Pokud se zapisují velká data mohou tato, pokud to inteligence controleru disku dovolí, nejspíš být zapsána přímo šindelově (nemuselo by být nutné načítat neměněná předchozí data k jejich následnému SMR zápisu). Nebo disky disponují hlavami pro celou SMR oblast a jsou schopny kompletního čtení/zápisu?

[qqqhhh]

Ano, SMR pouziva zony, najcastejsie 256MB. Kazda zona moze byt zapisovana iba sekvencne. Alebo resetnuta na zaciatok. Kazda zona ma svoj pointer kde sa aktualne nachadza. Ak chces zapisat do zony pred dany pointer, musi sa cela precitat znova a odznova zapisat.

Jednoducho nahodne zapisy vyzaduju reziu navyse - ak disk nema riesit casto cely zapis zony 256MB ,tak radsej sektor odlozi do 20G konvencej zony a tam ho necha az do momentu ked disku uz neprichadzaju poziadavky. Vtedy zacne zony prepisovat tak ze do nich vlozi nove data.

Hlava nevie precitat celu 256MB zonu naraz,to je prilis vela.

[Peter Golis]

Takže by stačilo spustiť zopár torrentov (sparse files) na rýchlejšom internetovom pripojení, a počkať. k to zdochne, tak sa preťažil prepis viacerých zón v SMR disku. Rozumiem tomu správne?

[PetebLazar]

To zni realne. Asi by muselo jit o rozsahlejsi soubory, aby nahodou vyssi "cache-hit-ratio" v non-SMR zone (tj. ze chunky budou urceny do stejnych SMR-zon) neomezilo celkovy pocet "uklidu" SMR-zon.

[Peter Golis]

Napr. inštalačné DVD nejakých linuxových distribúcií. To je fukot.

[qqqhhh]

ano torrenty su v tom najhorsie lebo sa stahuju po castiach a relativne nahodne. ale ako finalne ulozisko na seedovanie je SMR ok.