Citiraj:
Autor c-shadow
Možda mu se SSD pregrijao ili je neko QLC smetje od uređaja bez cachea.
Ubio ga je u pojam dok je kopirao podatke, nakon formata kod pisanja natrag se pregrijao i kontroler throttlea ili je SLC cache pun i eto sporog pisanja.
Nisam još vidio pristoajan SSD da loše radi bez obzira na scheduler i mount opcije.
Danas sve normalne distre automatski podese I/O scheduler bez da korisnik mora razmišljati o tome.
Ne bi me čudilo da na Arsch  distrama se mora i to ručno  |
Hm...hardwerski problem nije iskljuciv. Kaj se tice I/O Schedulera - i da i ne...vidio sam gadnih problema na Suse sustavima gdje je Udev rule po defaultu stavljao BFQ scheduler na SSD ploce ili 3par Storage. Rezultat je bio (naravno) katastrofalan performance. Na serverima preferiram mq-deadline cak i na klasicnim diskovima u RAIDu jer kad 1000-2000 korisnika odjednom preko Sambe hoce non stop nekaj piskarat 8 sati dnevno - kaos. A kaj se Archa tice...ma nije Arch losa distra, ako netko zeli zbilja nauciti utrobu Linux sistema - go for it. Odlicna dokumentacija i ak prezivis Arch forumase i ne uvrijedis se - ima potencijala. Ali to je to - nikad na prod i za po doma samo ako mi to nije jedina kanta ili imam fetis da non stop debuging neceg potrganog radim. Ako neznas sto radis ili ne zelis citat dokumentaciju Arch ce ti odgrist glavu, sjebat komp i plesat po tipkovnicici vicuci "RTFM!!!!!" (u ekstazi naravno). I to je za taj tip Distro-a cist OK. Fala al za mene je ta faza prosla pred 15 godina. Arch/Slackware su distra da korisnika bace u ocaj namjerno. Ali da bi zbilja bio produktivan u normalnom svijetu - treba se koncetrirat na manje "psycho friendly" distre iz RedHat / Debian / Suse asortimana.