Diit.cz - Novinky a informace o hardware, software a internetu

Uživatelský test: 8TB Seagate Archive na „domácí zálohování internetu“

Na domácích serverech mi začíná docházet místo, tak jsem se rozhoupal koupit kapacitně velký pevný disk s pěknou cenou za gigabajt. Myslím, že by byla škoda se nepodělit o malou uživatelskou recenzi, už kvůli specifickému „šindelovému“ zápisu.
Seagate Archive Hdd 8 Tb St 8000 As 0002

Jak jsem tak prováděl testy ve vzdáleném připojení, došel jsem až do stádia, kdy disk začal vykazovat něco, co bych si s drzostí sobě vlastní dovolil nazvat „aktivní nečinností“. Ve skutečnosti se nejednalo o nečinnost, protože disk samou „radostí“ z požadavků na náhodné zápisy nevěděl, kam dřív skočit. A tak se stala zajímavá věc, která vás v praxi zaručeně nepotěší: disk prostě a jednoduše přestal přijímat další data. Ne, že by házel chyby, ale měl dlouhé odezvy. Velmi dlouhé. Dostáváme se lehce k vysvětlení těch mnohasekundových lagů z recenze na StorageReview.

St 8000 As 0002 8 M

IOMeter - zápis: 8MiB bloky, z 50 % náhodný

To jsem si takhle pustil test v IOMeteru (něco jako tutus brutus na SSD) a ve výsledku pak pozoruji dlouhé výpadky. Celý graf odpovídá 15 minutám testu a uprostřed je zřetelná několikaminutová díra.

Další test nevypadal o nic veseleji:

St 8000 As 0002 1 M

IOMeter - zápis: 1MiB bloky, z 50 % náhodný

Zkusil jsem to s menšími bloky a pohořel jsem ještě víc. Test se prakticky pár minut po započetí testu zasekl.

Začal jsem (stále připojen vzdáleně) tušit nějaký problém a zkusil PC restartovat. Pak jsem pustil další test a záhy jsem ho přerušil, protože to nemělo smysl:

St 8000 As 0002 64 M Poresetu

Po restartu: IOMeter - zápis: 64MiB bloky, 50 % náhodný, po chvilce přerušeno

Iometer Zahlceni Disku

IOMeter - ukázka zahlcení disku

Začal jsme podezřívat IOMeter, protože už se mi párkrát v minulosti stalo, že se zbláznil a začal dělat psí kusy. Pustil jsem cvičně CrystalDiskMark a sledoval ve správci úloh zátěž disku. Test byl zahájen a v podstatě i doběhl, ale trval dost dlouho. Tak dlouho, že jsem byl schopen zaznamenat několik zajímavých úkazů. Všechny měly několik společných jmenovatelů: vysoká zátěž spolu s nulovou přenosovou rychlostí. Jinými slovy nezdravě dlouhá doba odezvy na požadavek. Tentokrát jsem vytrval, nechal jsem to doběhnout a po očku jsem sledoval, co se děje. Na obrázcích níže sledujte se mnou dobu odezvy ve správci úloh a systémový čas.

Crystaldiskmark Zahlceni Disku 10 32Crystaldiskmark Zahlceni Disku 10 34 1Crystaldiskmark Zahlceni Disku 10 34 2

(Sledujte mj. čas snímků vpravo dole)

Rychlosti zápisu 4,1 kB/s přibližně odpovídaly zapsanému jednomu „fyzickému sektoru“ (4096 bajtů) za požadavek, přičemž udávané odezvy hovořily o šílených desítkách tisíc milisekund neboli desítkách sekund. Vlastně jsem se reálně dostal na odezvu v řádu minut.

Protože se ale nikde neobjevila žádná chyba (ani v logu, ani nikde jinde, což mě překvapilo, čekal jsem nějaký zlý timeout), poslouchal jsem, co vlastně disk dělá. Pár disků jsem už za svůj život slyšel a tak nějak podle zvuku ramene s hlavičkami docela spolehlivě poznám, když se disk opakovaně snaží vypořádat s vadným sektorem. To ale rozhodně nebyl tento případ. Disk evidentně pracoval. Podle zvuku přesouval data ve větších blocích, v podstatě to klidně mohly být i ty ~128MB dávky odpovídající velikosti DRAM bufferu. Odkud kam přesouval, to jsem samozřejmě nebyl schopen poznat (a nepoznal bych to asi ani kdybych měl disk otevřený a viděl, co rameno s hlavami dělá).

Že se nejedná o aktivitu operačního systému, jsem poznal velmi snadno: indikační HDD LED téměř ani neblikla. Abych se ujistil, že to nemá s diskem nic společného, prostě jsem disk odpojil od SATA kabelu. Disk pracoval dál, jako by se nic zvláštního nestalo. Pořád přehazoval data jak uhlí lopatou. A vydrželo mu to celkem dlouho.

Napadlo mě, že by asi mohl být průšvih, kdyby se disku během této práce odpojilo napájení. Protože se ale takové věci stávají, udělal jsem to a po zastavení ploten jsem jej znovu zapojil. Disk po roztočení, inicializaci a krátké prodlevě opět začal přehazovat data. Bylo zřejmé, že uklízí po náročné šichtě náhodných zápisů. Z předchozí zkušenosti, kdy bylo jasné, že náhodné zápisy sype na plotny sekvenčně, vyplývalo, že si je prostě v době klidu rozhazoval tam, kam fyzicky patří (a soudě dle dlouhých lagů to zkoušel i v době, kdy jsem po něm stále chtěl, aby přijímal další data - neměl totiž kam sypat další, tak musel nejdřív uklízet a až pak byl schopen přijmout další data a do té doby se se mnou odmítal bavit).

Toto zahlcení pak může skutečně vypadat jako zátuh počítače. I obyčejná inicializace disku (zapsání tabulky oddílů typu GPT a vytvoření diskového oddílu) může trvat až nepříjemně dlouho, je-li disk zrovna ve stavu „vysoké podroušenosti“. Za normálních okolností to trvá i s tímto diskem pár sekund, jako s každým jiným.

Diskpart Inicializace PocatekDiskpart Inicializace Po 8 MinutachDiskpart Inicializace Po 25 Minutach

Diskpart - create partition primary - cca 25 minut

Je tedy zřejmé, že disk zápisy na náhodná místa realizuje nejprve sekvenčně a až pak, když má čas, nebo když mu dojde místo pro tyto náhodné zápisy, začne data uklízet na místo, kam patří. Otázkou je, jak velká je vlastně ta oblast, která je určena pro náhodné zápisy. K tomu jsem v IOMeteru vytvořil následující úlohu: 100% náhodné zápisy, velikost zapsaných dat 64 KiB. Disk jsem nechal několik dní v klidu, aby bylo jasné, že všechna data jsou tam, kde mají být a disková cache pro náhodné zápisy je „prázdná“. Tomuto testu jsem nastavil dostatečně dlouhou dobu trvání a sledoval, kolik se zapíše celkem dat, než se disk brutálně zpomalí.

Trvalo to chviličku, jen dvě a čtvrt minuty. Během tohoto času se průměrnou rychlostí lehce pod 90 MB/s průměrnými 1330 IOPSy zapsalo něco přes 11 GiB, neboli necelých 12 GB. Tolik zápisů menších než 1 zóna disk snese na jeden zátah. Šlo by to samozřejmě i rychleji, ale já neřešil paralelizaci nebo větší bloky, dělal jsem to podobně jednoduše jako HD Tune na předchozí stránce, který též u 64KiB bloků došel k číslu něco přes 80 MB/s a lehce přes 1300 IOPS. I tak je průměrná přístupová doba v takovém případě pod 1 ms.

Poté se tedy disk zpomalil na brutální hodnotu a začala se z něj ozývat intenzivní práce. A teď se prosím pěkně ujistěte, že sedíte, protože vám řeknu, jak přibližně dlouho tato práce trvala, než se disk uklidnil: bylo to více než 14 hodin (pak už mi v záznamníku došlo místo a když jsem na to po dalších 5 hodinách přišel, disk už byl klidný, takže to bylo něco mezi 14 a 19 hodinami - zkrátka dost dlouho na to, že tuto činnost vygenerovala práce trvající pouhých 2 a ¼ minuty).

Neznamená to, že po necelých 12 GB náhodných zápisů musíte tak dlouho čekat, než na disk něco zapíšete, ale počítejte s tím, že rychlost zápisu klesá poměrně rychle až na jednotky sektorů za minutu. Disk je prostě určen primárně pro velké sekvenční zápisy, takže při výběru s tím počítejte.

Tagy: 

WIFT "WIFT"

Bývalý dlouholetý redaktor internetového magazínu CDR-Server / Deep in IT, který se věnoval psaní článků o IT a souvisejících věcech prakticky od založení CD-R serveru. Od roku 2014 funguje v jedné mezinárodní firmě jako databázový administrátor a psaní článků už fakticky pověsil na hřebík.

více článků, blogů a informací o autorovi

Diskuse ke článku Uživatelský test: 8TB Seagate Archive na „domácí zálohování internetu“

Čtvrtek, 23 Listopad 2017 - 15:58 | WIFT | Náhodou jsem sem zabrousil - disk hélium nemá a...
Neděle, 10 Září 2017 - 22:43 | KingJack | WIFTe, prosím tě, jeden stupidní dotaz. Rozumím...
Středa, 18 Leden 2017 - 22:05 | Srandista | Chcem len upozornit kazdeho, kto najde tento...
Čtvrtek, 29 Prosinec 2016 - 12:51 | Lukas Lukas | Dobrý den, chtěl bych položit dotaz. Je možné, že...
Středa, 15 Červen 2016 - 10:14 | Martin Prokeš | Neuvěřitelné! Takhle detailní, důkladnou a...
Úterý, 14 Červen 2016 - 12:46 | Aigor | To je mi jasné, proto tento údaj uvádím....
Úterý, 14 Červen 2016 - 09:46 | WIFT | Jak bych to udělal já. Dejme tomu, že buffer je...
Úterý, 14 Červen 2016 - 09:24 | WIFT | To krapet nekoresponduje s tím, co mi předvedl HD...
Pondělí, 13 Červen 2016 - 15:37 | tmp | Evidentne to nikoho zaujimat nebude, resp. iba...
Pondělí, 13 Červen 2016 - 15:29 | Aigor | Jen pro doplnění - kompletní přepis disku = 10,3...

Zobrazit diskusi