Administrace komentářů

Už jste to vyřešil sám, závěr je pro mě osobně dost překvapivý a zajímavý, gratuluji a děkuji za informaci. Na SATA disk připojený přes LSI SAS řadič funguje "hdparm"? No to je geniální... ještě kdyby fungoval smartctl

Snad jen pár poznámek na okraj:

Z Vašich poznámek jsem nabyl dojmu, že řadič "HP" (LSI) používáte jako tupý HBA a RAID 10 používáte nativní Linuxový softwarový (ne nějaký proprietární soft-RAID ovladač od LSI). Pokud je to tak, děláte to správně.

Ten původní SATA řadič od AMD byl obsluhován jiným driverem (něco v rámci libata nebo stand-alone driver ve "scsi low-level drivers") než Váš nový řadič, který je podle všeho osazen čipem LSI SAS z rodiny Fusion MPT (ovladač mptsas.ko?). Možná je rozdíl v zacházení s cache uvnitř disku daný právě tím. Driver LSI message/fusion býval zaháknut do vrstvy blokových zařízení, spíš než do jednotné kernelové vrstvy SCSI - to už zřejmě není pravda, ve zdrojákách je spousta odkazů na obecné linuxové SCSI struktury, takže staré časy už asi připomíná jenom samostatný adresář ovladače, mimo jednotný drivers/scsi...

Pokud se nepletu, tak SATA NCQ stejně jako SCSI/SAS/FC TCQ je mapováno na jednotný queueing SCSI požadavků linuxové SCSI vrstvy. (Aspoň doufám, že si to ovladač message/fusion dodnes nedělá sám...). Každopádně pokud se nepletu aktuální default queue depth v ovladačích LSI je tuším 128 (bacha, nejedná se zřejmě o položku CONFIG_FUSION_MAX_SGE v .config, ale spíš o podobně znějící makra v souboru mptbase.h.)

Dále si přihřeju polívčičku: zatímco Bonnie je benchmark a tester souborových systémů, já mám jednoduchý tester na sekvenční a "random access" průchodnost blokového zařízení - výsledky jsou vidět okamžitě a jsou poměrně pochopitelné:

http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz

sice to taky jede skrz blokovou cache (žádný O_DIRECT) ale dává to docela rychlý přehled o zdravotním stavu disku/řadiče/PCI, pokud víte, kolik zhruba máte čekat. Je z toho třeba na první pohled vidět Intel ICH SATA řadič nastavený do suboptimálního režimu (pokud je použit) nebo disk s vážnými problémy (kolísání sekvenční rychlosti).

Dnešní Barracudy mají příjemnou sekvenční průchodnost, ale rychlost seekování není nijak závratná - vyšší hustota záznamu zřejmě vyžaduje delší dobu ustálení po každém seeku. Nejnovější cheetahy 15k seekují nejmíň dvakrát rychleji. Každopádně dnešní Barracuda by ani v tomto ohledu neměla být znatelně horší než 3-4 roky starý disk. Spíš pozor na závadu konkrétního kusu - nápadně pomalá průchodnost jednoho disku může znamenat blížící se vadné sektory a typicky brzdí celý RAID. Pokud máte možnost otestovat disky jednotlivě (aspoň na čtení to jde i při nahozeném RAIDu), tak je trochu provětrejte.

Ohledně write-back cache: moje zkušenost je, že s vypnutou write-back keší se prakticky nedá pracovat. Pro většinu použití to není zásadní problém - vypnutí WB cache zvažte jenom v případě, že se *opravdu hodně* bojíte o svá data.

Ti LTSP klienti, jak velké soubory vyrábějí? Na maličké soubory by možná byl lepší Reiser 3...

Taky jsem měl svého času pocit, že mi za jistých okolností CFQ serializuje čtecí požadavky od více vláken, takže se mi požadavky nerozložily mezi více "spindlů" v RAIDu. Přechod na čistý FIFO scheduler ("noop") přinesl zásadní nárůst průchodnosti (lepší škálování) při paralelním přístupu více user-space vláken. (echo "noop" > /sys/block/hda/queue/scheduler). Ale to se týkalo přístupu k HW RAIDu na 24 discích - pro 4 disky ten rozdíl nemusí být výrazný. Měl jsem pocit, že když použiji ovladač pro Qlogic HBA zakompilovaný monoliticky, tak mi CFQ funguje rozumně, ale když ho zkompiluju jako modul a loadnu až za jízdy, tak se CFQ pro nově detekovaný disk chová popsaným způsobem...