Šoupání s daty (diskuse)

[Mrkva]

tak jsem si řekl že to už by mě opravdu sakra mrzelo, kdybych o ta data přišel

...

a LVM logický oddíl naformátoval na btrfs

Ehm...

[Aleš Kapica]

V tom blogu jsem neuvedl časovou osu - nepovažoval jsem to za nutné, ale btrfs používám už třetím rokem bez nejmenšího problému. A osobně se domnívám že pro účely datové storage je to to z linuxových souborových systémů ten nejlepší co se dá použít.

Ještě jednou opakuji - datové storage. Btrfs se totiž svou podstatou nehodí jako podkladový souborový systém pro virtuály. U těch není komprese datových bloků žádoucí, takže tam používám ext4. Koneckonců - u těchto strojů se o data stará vnitřní souborový systém.

Stejně tak se nehodí - tedy přesněji řečeno se nehodil - Btrfs na systémový disk. A to z toho důvodu, že nebylo možné na něj aplikovat fsck. To však již neplatí.

Nad LVM oddílem je Btrfs naprosto v pohodě, protože dovoluje bez problémů měnit velikost všemi směry - prakticky odzkoušeno. A jeho vlastnosti ocení obzvláště ten kdo používá takhle velké diskové oddíly.

[Mrkva]

Já jen, že v jádře není oflagovaný jako EXPERIMENTAL jen tak z legrace. Nebo je?

[Aleš Kapica]

To určitě ne. Ale když se to porovná s ext4, tak ač experimentální fs, se mi jeví dlouhodobě jistější. A ten pocit je založený především na jeho praktickém použití.

[Trained.Monkey]

Proste to vis lip nez jeho autori

Sam pisu DB (podobne fs), ale svoje data bych ji nesveril minimalne dalsich nekolik let.

[Aleš Kapica]

1. Kdyby nebyl btrfs použitelný, tak by nebyl v jádře
2. To jestli je nějaký FS součástí kernelu a zda-li je označený jako EXPERIMENTAL, nebo ne, není pouze otázka jeho kvality a spolehlivosti, ale především politika. Viz Reiser4, který jsem používal ještě před btrfs
3. Pokud máš argumenty, které by dokládaly opak, tak sem s nimi
4. Pokud píšeš DB, které nevěříš natolik abys jí svěřil svá data, tak to není moc dobrá vizitka pro tvou práci.

[kotyz]

To tam bude minimálně do tý doby než pro něj bude funkční fsck. Na mě je btrfs moc inovativní a novej, tak sem radši přemigroval z ext3 na ext4, ale až tak o rok nebo dva pozdějš než ostatní. Pořád sem s tim váhal a nechtělo se mi do toho. Teď se mi zas pár let nebude chtít to migrovat na něco jinýho.

[Heron]

Mě na tom více zaujalo to BTRFS nad LVM. Btrfs má vlastní multi device manager.

I když z tohoto:

tak jsem si řekl že to už by mě opravdu sakra mrzelo, kdybych o ta data přišel

asi plyne, že Aleš ta data nezálohuje. Asi je nepotřebuje.

[Aleš Kapica]

Docela by mě zajímalo jak by sis představoval zálohování takového kvanta dat. Já došel k tomu co mám evolucí. Uvažoval jsem i o použití zálohování na blue-ray disky - jenže na takovou diskotéku nemám čas. Ta data jsou totiž stále živá. V tom smyslu, že je přehazuji, přejmenovávám, třídím, upravuji. Ovšem pouze když se na to najde chvilka. A nepředpokládám, že bych s tím byl někdy hotov.

LVM pod Btrfs mi dává větší flexibilitu a kontrolu nad tím co kam je připojeno. A taky to více odpovídá filosofii původního unixu. Je sice fajn, že bych mohl sestavit raid přímo v Btrfs. Jenže to samé bych mohl i přímo v LVM, a přesto to nedělám. To raději oželím část výkonu.

Důvod? Firmware disku, SW raid, i btrfs, mají své opravné mechanismy. U každé vrstvy se může vyskytnout chyba a čím je jich více, tím je její výskyt pravděpodobnější. Ovšem na druhou stranu je o to nižší pravděpodobnost, že se ty chyby sejdou současně na jednom místě.

[Heron]

Docela by mě zajímalo jak by sis představoval zálohování takového kvanta dat.

Já mám v kompech dohromady asi 5TB diskového prostoru, kde je asi 3.5TB dat, a protože o ta data opravdu nechci přijít, tak k tomu asi 4.5 TB externích disků pro zálohy. Zálohování však nemám automatizované. Zkrátka kdykoliv mám pocit, že jsem od minulé zálohy udělal nějakou důležitou změnu (jednou, dvakrát do měsíce), tak to nasypu na externí disky. V případě, že komp lehne popelem, tak nepřijdu o všechno. Mít všechny disky neustále online, to bych byl hodně nervozní.

[Aleš Kapica]

To je domácí komp. Tam ty disky nejsou pořád on-line.

[Heron]

No ale ten komp je jedinné fyzické umístění těch dat, ne? Když to celý chcípne (neštastně umře zdroj a vezme s sebou i disky), tak jsou data fuč.

[Aleš Kapica]

Zažil jsem už leccos, i mí kolegové, ale o tom že by zdroj sebou sebral i disky jsem pouze slyšel. Po pravdě řečeno mi to přijde méně pravděpodobné, než to že bychom (opět) vyhořeli - a v takové situaci už by mi to bylo asi srdečně jedno. Na to abych udržoval paralelní zálohu mimo bydliště fakt nemám. Čas, infrastrukturu ani prostředky.

Mimochodem to je jeden z důvodů proč jsem přesvědčen o prospěšnosti sdílení filmů, knih a audio souborů. Bohužel spousta zajímavých věcí je už pravděpodobně po povodních v r. 2004 nenávratně ztracena. Kdyby existovaly elektronické kopie, které by bylo možné volně sdílet, tak by se bezpochyby pro řadu z nich našli lidé, ochotní věnovat svůj diskový prostor pro uložení jejich lokální kopie.

[Aleš Kapica]

A že časem pořídím i nějaký zálohovací NAS jsem nijak nevyloučil. Momentálně takto funguje právě zmíněný stroj, kam čas od času přesouvám data která jsou na noteboocích. Objemná data, která jsou určená pouze pro občasné použití - jako audio a video soubory, se na nich pouští skrz NFS.

Původní záměr - totiž aby to jelo jako server pořád jsem vyloučil z důvodu spotřeby. I když je proti obvyklému průměru extrémně nízká, stále je to hodně. Navíc žena i babička jsou děsně nervózní z modré kontrolky na desce. Svítí hodně intenzivně a tak mají pocit že to žere mnohem víc než odpovídá realitě. Jinak před výpadkem napětí a proudovými nárazy ho chrání UPS s přepěťovkou.

[Gilhad]

Co takhle HW řešení human problému - kontrolku zatemnit ať už odporem, nebo sklíčkem, nebo prostě fixou? Nebude svítit tak intenzivně a spotřeba rázem klesne na akceptovatelnou úroveň.

(Stejně jako mě skorotchyně chválila za pomalou a opatrnou jízdu, protože jsem měl zařazený vyšší stupeň a motor tak jel tišeji v nižších otáčkách, ačkoli auto se pohybovalo podstatně rychleji než referenční vůz :) )

[Trained.Monkey]

Ty se bojis ztraty dat a pouzivas Btrfs? Hm...

Vsude pouzivam Ext4, par partition pro Vmware ma Ext2. Moje konfigurace disku:

1) 64 GB SSD s roof a home. Home je kryptovany pomoci Ecryptfs z Ubuntu, dost to zjednodusuje organizaci dat. Na tomhle disku mam "svoje zivobyti" je to asi 40GB.

2) 1TB rychly disk pro ruzna data, fotky, hudbu apod. Vsechno je pomoci symlinku z home transparente integrovane. Tady jsou data pro ktera si trhat zily nebudu ale zalezi, asi 600 GB.

3) Nzkootackovy 2 TB disku na filmy a zalohy. Partition se zalohami neni obvykle mountnuta.

Raidu moc nemusim, prijde mi moc slozity na konfiguraci a udrzbu. Navic potrebuju spise neco obnovit z historie, nez mit aktualni system.

Data z 1) maji rsync kazdou hodinu na 2) a 3). Nechavam si poslednich 48 zaloh (dva dny).

Data z 1) a 2) kazdou pulnoc rsyncuju na 3). Tady nechavam 60 zaloh (2 mesice).

Data z 1) a cast 2) kazdy tyden zalohuju na prenosny USB disk. Po zbytek tydne je disk dobre schovany.

Pokud potrebuju delat na notebooku nebo obnovuju zalohu, tak proste zkopiruju data, upravim grub a jedu.

[Gilhad]

ext4 taky umí dělat podivuhodné věci se soubory (hlavně přičarovat délku 0), nebo alespoň nedávno umělo, dle jaderných novin. Na vině byly prý aplikace, které se k tomu chovali jako k ext2/3 a spoléhaly na něco, co norma nevyžadovala a ext4 tudíž nedělalo. Jasně že chyba je v těch aplikacích, ale když jsou data v čudu, tak to nepotěší, ať už je přímý viník kdokoli. (A možná tam jde něco zapnout, aby se to "chovalo postaru, jak aplikace mylně očekávají", už si nevzpomínám)

[kotyz]

To už je asi dva roky vyřešený (nebo spíš obejitý) a defaultně je ext4 nastavený tak aby se tomu předcházelo (chová se jako ext3 v ordered mode).

[Aleš Kapica]

No. Nejsem si tak zcela jist. Systémový SSD disk je na ext4 a už mě opět vypekl. Soubory z otazníčkama místo práv jsem už dlouho neviděl. U kompu bez možnosti nabootovat odjinud docela prekérka.

Jinak btrfs používám na data s nimiž se moc nešoupe - tam se mi to osvědčilo. Na systém obvykle používám léty prověřený a osvědčený reiserfs. Teď jsem však učinil výjimku - kvůli SSD disku, kterému způsob jak pracuje reiserfs příliš nesvědčí.

[Gilhad]

Taky mám v dlouhodobém plánu udělat centrální zálohu a pořádek. Až jednou bude čas a nálada. Zatím jsem vymyslel pár triků, které by se mohly (a nemusely) hodit:

• nechat si sjet obsah disku pomocí md5sum do (mega)souboru (a mít pak možnost si ověřit, že se nic neztratilo/nepoškodilo - máloco naštve víc, než když člověk zjistí, že má soubor zálohovaný na deseti místech, ale všude už je verze s chybou)
• tento soubor seřadit dle hashe a najít tak snadno duplicity obsahu (nikoli jména) - například pic12345.jpg = pic12345-rybnik.2011.zari.jpg = 2011.09.dovolena.rybnik.jpg
• nacpat to do databáze kde jako jeden z indexů bude ten hash. Kromě jiných skopičin bude snadné u nového souboru spočíst md5 a vyhledat v databázi, zda ho už nemám
• protože md5 mám i na archivních CD/DVD, tak budu schopen v databázi dohledat snadno, o co vše jsem přišel kvůli nečitelným mediím a tudíž bych měl zkusit najít jinde (když jsem to z jednoho CD nepřečetl a z jiného přečetl, nemusím to hledat, už to mám - čili pouze seznam nečitelných nestačí)

Určitě se najdou i další využití, časem ...

[Aleš Kapica]

Tohle jsem dělal právě v té fázi sjednocování. Udělal jsem si na to skript. Každý z disků jsem zkopíroval do jednoho adresáře a pak jsem si sjel ty kontrolní součty. Ten skript je pak porovnával.

U souborů, které měly shodný kontrolní součet ponechal v jednom exempláři ty co byly na důveryhodnějším svazku a ty co se lišily ponechal. Zredukoval to na nějakých 30GB, a když mám čas, tak se tím probírám. Díky tomu že to mám v jednom prostoru mi nové duplicity tak často nevznikají a objeví se jenom sem tam. Když na nějakou přijdu tak soubor smáznu a je hned o chlup více místa.

[D-Evil]

Pokud máte svoje data hodně rád, doporučil bych ještě v případě shody md5 hashů provést i skutečně porování souborů. Shoda md5 hashů neznamená nutně shodu dat. Běžně toto dělají např. virtualizační nástroje při deduplikaci RAM, protože tam může každá chyba hodně bolet.

[JS]

To "doporucil bych" znamena "setkal jsem se s tim v praxi" nebo "uveril jsem nejakym reklamam o tom, ze je to k necemu"? I kdyz ja bych misto MD5 pouzival SHA1, a databazovy system, ktery to dela (a castecne ho popsal Gilhad vyse) to taky tak ma.

[Gilhad]

Pokud dva soubory mají stejnou délku, měly by podle jména mít stejný obsah a md5 sedí, tak celkem věřím, že sedí i ten obsah. Dvě vzájemně různé verze obrázku se stejnou md5 jsem zatím buď nepotkal, nebo nerozpoznal.

[j]

Ze by nahodne vznikl soubor se stejnym MD5 ale jinym obsahem je situace nikoli nerealna, ale pocitam ze tech nul za nulou a carkou v procentech bude hodne moc ... Predpokladam, ze pravdepodobnost uspesneho teleportu osoby z mista A na msto B je vyssi.

[JoHnY2]

A pokud by mel clovek spatnej pocit, tak pri dnesnich vykonech vetsinou neni problem sahnout po SHA-256 kde je sance kolize "kapku" mensi.

[Heron]

nechat si sjet obsah disku pomocí md5sum do (mega)souboru (a mít pak možnost si ověřit, že se nic neztratilo/nepoškodilo - máloco naštve víc, než když člověk zjistí, že má soubor zálohovaný na deseti místech, ale všude už je verze s chybou)

Možná by bylo lepší nechat md5 konečně v klidu umřít. Používám SHA512.

nacpat to do databáze kde jako jeden z indexů bude ten hash. Kromě jiných skopičin bude snadné u nového souboru spočíst md5 a vyhledat v databázi, zda ho už nemám

Já jsem dřív přemýšlel (potom jsem objevil squashfs a ještě potom btrfs) o ukládání dat (nejenom nějakého seznamu) do DB a jejich deduplikaci (dle bloků, nikoliv celých souborů). Ale než se z myšlenky stal návrh, tak už tu jsou FS, které to umí / budou umět.

tento soubor seřadit dle hashe a najít tak snadno duplicity obsahu (nikoli jména) - například pic12345.jpg = pic12345-rybnik.2011.zari.jpg = 2011.09.dovolena.rybnik.jpg

fdupes; hardlink

[Gilhad]

mě se ještě nechce, některá data sahají do doby RedHat 6.1 a občas vylezou z nečekaných koutů.

fdupes jsem neznal - taky používá md5 - a když já už ty md5 mám, tak to vyhledání je celkem snadné. Navíc ne vždy to jde jen bezhlavě smazat či nahradit hardlinkem - některé vývojové větve i nesouvisejících projektů ptřeba občas obsahují dočasně stejný kód, který se rozdělí až později (typicky u mě různé konfiguráky) - smazání znefunkční větev, hardlink rozhodí druhou/třetí/další větev při změně.

[Heron]

Navíc ne vždy to jde jen bezhlavě smazat či nahradit hardlinkem - některé vývojové větve i nesouvisejících projektů ptřeba občas obsahují dočasně stejný kód, který se rozdělí až později (typicky u mě různé konfiguráky) - smazání znefunkční větev, hardlink rozhodí druhou/třetí/další větev při změně.

Jo jo. Na tohle se lépe než hardlinky hodí reflinky.

[gtz]

Aleši, 3GB disky jsou již běžně k dispozici, mělo by se jednat o model ST33000651AS. Ale cena 5800,- za kus je něco strašného. Ale je to pouze model pro desktopy, tedy nic pro servery. Ona by měla stačit i R5 s jedním spare diskek. U R6 je výhoda, že mohou vypadnout dva disky, ale když vypadnou tak pole je pomalé jako prase a resynchronizace je celkem hustá. No a R5 s spare je o něco rychlejší. Když jsem toto dělal tak jsem na toto používal výhradně XFS systém.

[Aleš Kapica]

To já vím, že jsou k dispozici. Nicméně jsem spokojen s tím co jsem koupil - SEAGATE Barracuda 7200.12 2000GB s Advanced Format. Pole z 3TB disků se cenově nevyplatí. Ten datový nárůst nestojí za řeč v poměru k tomu kolik bych za něj zaplatil.

Předpokládám, že s tímhle polem vystačím tak dva až tři roky. Jako zálohu - kdyby bylo akutně třeba více místa mám ty dva starší pomalejší 1TB disky. Složil bych z nich zase raid 1.

Podle toho co jsem zachytil za zprávy, tak se disky s 5TB připravují do výroby. A za tu dobu by snad už mohly být i v rozumné cenové relaci. Něco jiného než SATA III stejně hned tak asi nebude a v kompu bude po stěhování místo pro další 4 disky - zatím mi na tom visí ty disky ze kterých se to přesouvá a které půjdou pryč. Celkem je teď zapojených 10 disků. Pak za běžného provozu jich bude jen 5 (4x2TB rot. + 1x60GB SSD)

Do raid5 bych nešel. Bůhví co bude za ty dva tři roky. Ty laciné disky mají větší pravděpodobnost výskytu chyby. Toť vše. Nelze předem říct, které z nich se vysypou dřív. Takhle mám ale možnost ustát i dva chcíplé disky a připravit se mezi tím na podobnou investici jako teď.

[Aleš Kapica]

Ten stroj co mám doma jsem poskládal za nějakých 18 tisíc. Velké datové úložiště je v něm proto, že ho mám mimo jiné v plánu používat jako základ pro knižní skener - po elektronické stránce již všechno mám, včetně synchronizované spouště. Stroj má mimo jiné dvě TV karty s analogovým vstupem pro obraz s foťáků - kvůli ostření. Deska s AM3 má již SATA III a USB 3.0 V té ceně stroje jsou započítané i dva SATA III řadiče (každý se dvěma porty). Stroj je velmi tichý i když pochopitelně když se na ten zvuk člověk soustředí, tak slyšet je. Nicméně čerpadlo v akvárku je mnohem hlučnější. I s monitorem to má spotřebu 100W (se šesti disky) - měřil jsem to. Stavěl jsem to před rokem.

S těmi novými disky se cena vyšplhala cca na dvojnásobek, ale kapacita je větší a měla by být vyšší i rychlost, neboť už je všechno na SATA III. Musím ale ještě přeházet kabely. Teď jak jsem to zapojoval tak narychlo mám dva nové disky na jednom z těch řadičů a ten tak má poloviční přenosovou rychlost.

Není však vyloučeno, že to v budoucnu sakumprásk nahradí nějaký NAS, který vykopnu na balkón.

[gtz]

Použil bych klidně i R5 s disky pro raid (RE od WD nejsou špatné, ale já preferuji ST)

[Aleš Kapica]

Jinak jak to je pomalé, když vypadnou dva disky vím teď. Kopíruji na ně data O to víc se těším, až to dojede a já budu moci uvolnit dvě pozice, abych mohl ten raid doplnit na plný počet disků.

[gtz]

Jenže bacha, když máte pole v degrade modu pak stačí chybka někde na káblíku apod. a pole je rozesyncované a dávat to pak dohromady je někdy problém. Ideální je jak jsem psal, nechat resyncout pole na R5 v plné palbě, pak jej zatížit a pak teprve kopírovat ostrá data. (dělám nějakou dobu od 2003 disková pole, storage, FC apod.) a vím dobře jaká jsou úskalí a kde jsou ostatní hrdla. Pomalé to je a bude i tak (budeš muset dopllnit jeden disk+ celé to syncnout a to stejné u druhé disku a v tu dobu se může stát, že někde něco).

Ale ceny jsou brutus, nedávno jsem dodával pole v 2U,Xeonem, 12GB RAM, 12x 1TB za cca 2500€. Dneska ta samá konfigurace stojí od 3990€. Na soho dodávám malé domácí pole pro 5-7 disků taky s Linuxem a cena pro Tower s Areca R6 + 7x 1TB disků cca 1600€

Držím palec aby to bylo jak má být.

[Aleš Kapica]

Zrovna jsem ti chtěl napsat - nemaluj čerty na zeď a už tam byl kernel panic.. 8-)

Inu, zbrklost se nevyplácí - přendal jsem z toho degradovaného pole s 64 chunky ten třetí disk a přendal ho do toho co se na něj kopírovalo jenže tomu to neudělalo moc dobře, tak jsem ho zase vyndal. Ale asi mu něco popletlo hlavu.

Takže jsem teď zvolil menší zlo, sebral disk z 500G raid 1 - ten to snad přežije, než se to dokopíruje. Přinejhorším kdyby se podělal, tak ho obnovím z toho vyškubnutého. A místo něj zapojil ten záložní 2TB disk, ať jsou ty disky v obou polích alespoň tři. Holt musím s přehozením počkat až se to dokopíruje. Zítra na to bude mít celý den.

[gtz]

dělám ty pole nějakou dobu a když něco píšu tak vím co se může stát. Jak jsem psal nechat syncnout prázdné pole a pak teprve copy.

[Aleš Kapica]

Taky to tak dělávám. Ovšem občas pod tlakem udělá člověk různé blbiny. Obzvláště na vlastních datech. Naštěstí (ťuky ťuk) se mi ale už dlouho nestalo, že bych někdy udělal tak fatální botu, že bych o nějaká data nenávratně přišel.

O svá nejstarší data z doby, kdy jsem ještě nevlastnil PC ani notebook (1994/96) jsem přišel, když jsem je bláhově svěřil do úschovy na disk kámošovi. Jenže ten na to po čase jaksi pozapoměl, adresář mu nic neříkal a tak mi všechno smáznul. Takže mi zůstalo jen to, co jsem měl vytištěné.

Mě se později rovněž podařila podobná bota. Odzálohoval jsem data z notebooku na CD. Kouknul se zdali tam všechno je, namátkou zkusil jeden dva soubory - vše ok. Takže jsem s klidnou duší disk přeformátoval a (Windows 98 se) přeinstaloval. Večer pak dorazil kolega, že prý tam měl rozdělanou diplomku. Vytáhnem zálohu... ..a nic. Na CD byla jen struktura adresářů a pár souborů. Zbytek dat nikde. Jak na potvoru jsem se při zkoušení, trefil na soubory, co byly ok. Od té doby jsem k formátování a mazání souborů poněkud zdrženlivější a i to je důvod, proč se toho nahromadilo tolik. Na CD či DVD také není zrovna spolehnutí a na uchovávání dat, s nimiž se pracuje se moc nehodí.

[gtz]

jenže poslední dobou jsou disky nějak moc divoké (prostě to nejsou ty staré Seagate gumáky co vydržely hodně). Novější disky v rámci miniaturizace jsou celkem hodně očesané a snad jen SAS/FC disky tímto netrpí. CD/DVD nějakou dobu vydrží, ale nedávno jsem potřeboval přečíst jedno CD z roku tuším 1994 a měl jsem problémy. Nakonec jsem snížil rychlost na 1x a čekal jsem a čekal jsem. Jak říká jeden můj známý, raději to mám 2x než abych o něco přišel.

Kdysi jsem zkoušel v rychlosti poskládat pole, nechal jsem to synchronizovat a začal kopírovat data z druhého vadného pole. Když tam byla půlka tak si disk cvaknul a bylo to. Jako nic mu nebylo, prostě Molex. Dlouhá práce pryč, tak se muselo začít znovu, a musel jsem dávat hodně bacha na to staré pole, které jelo v degradu (R5) s jedním padlým diskem.

[the.max]

zish, k cemu takova diskova kapacita? Vzdyt porno neni nutny stahovat do pocitace, denne se objevuje na netu nove a nove

[D-Evil]

Ale samo se nestáhne

[Gilhad]

Jen počkej až přijde ACTA, budeš rád i za nalezenou disketu :)

[Aleš Kapica]

Kristepane. Shlédnout takovou dávku porna, tak mě vezou do cvokárny.

Mám tam všechny data, které se mi nasbíraly za posledních 15 let.

[Aleš Kapica]

S tím, že je tam hodně dat, které čekají na zpracování, "až se někdy najde čas" No a to jsou ty data, které průběžně nahrazuji.

[Walkeer]

Vsechny dostupne benchmarky se shoduji v tom, ze realne zrychleni SATA III oproti SATA II je maximalne v radu procent. Je to logicke, jelikoz maximalni prenosove rychlosti dosahovane 7200r disky jsou cca 170Mb, coz rozhodne neni strop SATA II, ktera ho ma na cca 270MBps. Vase zjisteni, ze se doba po vyhozeni SATA II disky zkratila na polovinu je silne zavadejici a v zadnem pripadne nemuze souviset s pouzitym radicem, je to zrejme spise vlasnot onoho starsiho disku.

[Aleš Kapica]

Jo, to máte bezpochyby pravdu. Jenom pro upřesnění udávám že šlo o disk (ST32000542AS s firmware CC34), který má jenom 5900 otáček a "Sustained data transfer rate" 95Mb/s, kdežto pro ty nové disky Seagate udává 210Mb/s.

Faktem však je, že Seagate takhle velké disky na SATA II s větším počtem otáček snad ani nedělal. Takže platí co jsem uvedl v blogu - nevyplatí se sestavovat takhle velké pole jako mix SATA II a SATA III disků.

Na desce mám pouze SATA III porty, takže nemohu dost dobře srovnat, jak by si co do rychlosti tohle pole vedlo na řadiči SATA II.