Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.
Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.
FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.
Predikovatelna... hmm a proto jsme u Sunu meli velkou testovaci farmu kde bezely ruzne scenare tydny i mesice. Stejne se neprotestovalo vsechno a prvni verze zhucely na primitivnich use cases typu "hu-man u konzole" si spletl disky a nebral v potaz ruznou velikost bloku disku. A kazda blba feature se musela protestovat mnoha scenari. Milionkrat jsem ten filesystem rozmlatil abych mu veril i v krajnich pripadech.
Takze predikovatelne to mozna teoreticky je, prakticky je tam tolik ruznych kombinacia edge cases ze to neni mozne postihnout vsechno. Pokud se nasla nejaka bota tak se slo zpetne po testech a zjistovalo se proc to nezachytily. Dost casto za to mohl prilis synteticky charakter testu.
Prijde mi tedy ze dost podcenujete komplexitu ktera u BTRFS musi byt srovnatelna.
A jak se testuje profesionalne BTRFS? SuSE/Meta? A nevymezi testovani jen na pro ne momentalni kriticke features a v produkci bezi zmrazena stabilni verze?
Z tohoto duvodu bych pro NASku aspon nepouzival experimentalni features a mel po ruce implementaci ktera se nekde pouziva a nebo podporuje pro koncaky.
30 Odpovědí
56788 Zhlédnutí