A videl jste nekdy soucasne modely SSD? Hlavne ty na SATA Gen.3, jez uvadi rychlost zapisu pres 500MB/s ... ta rychlost je dosazena kompresi na disku, pokud tam budete cpat komprimovana nebo sifrovana data, dosahnete asi 290 MB/s.
Odstranenim komprese a sifrovani vlastene rikaji ze SSD ma budoucnost - a ostatne proc ne, kdyz dana komprese spotrebu disku nezvysuje a uvolni cykly na CPU.
A sifrovani.. to je kapitola sama o sobe - vedome ji nenasazuji. A ani nebudu - SSD ktere me posledne odeslo sifrovalo i kdyz nemuselo a jediny vysledek je, ze mam ted data neobnovitelna ani kdybych precetl flash cipy - protoze ani vyrobce disku ani radice neposkytne info o ukladaci metode a jejich 'sifrovani'. :(
Ani jedno není důvod, proč by to neměl souborový systém podporovat (je to volitelná vlastnost), hlavně u serveru, kde SSD ještě pár (desítek) let používáno nebude. Navíc šifrování v souborovém systému bývá dokumentované (a je i u NTFS), takže není problém udělat si vlastní implementaci, na rozdíl od hardwarového šifrování na discích. Pokud by však tohle byl důvod, proč tedy MS rovnou nezahodí podporu pro SW RAID a místo toho ji ještě rozšiřuje, když všechny dnešní řadiče RAID jakž takž (asi jako to šifrování) podporují?
K tej obnove dat... Tie treba totiz aj pravidelne zalohovat na externe medium a netreba potom riesit ako to z toho dostat. Softverove sifrovanie by som urcite doporucoval u notebookov a dalsich malych zariadeni, ktore su lahko ukradnutelne a u klasickych diskov aj v pripade, ze tam su data, ktore nemozem pustit z ruky a zaroven by som rad disk vyreklamoval ak odide v zarucnej lehote.
S prvním argumentem ohledně komprimování příliš nesouhlasím.
Pokud mám vycházet z níže uvedeného článku, kde je porovnána rychlost zápisu 4MB souboru: 438MB/s pro zero-fill soubor a 254MB/s pro nekomprimovatelná data, tak mi to přijde dost zavádějící.
První soubor se zapíše výrazně rychleji, ale neobsahuje žádnou informaci, na rozdíl od druhého souboru. Když zero-fill soubor (nebo jakýkoliv jiný) komprimujeme už na CPU, bude jeho zápis na disk taky rychlejší. Čili tohle jako argument neberu. Že tím odlehčíme CPU, s tím souhlasím.
Když to trochu přitáhnu za vlasy, tak podle stejných měřítek by nemělo být těžký sestrojit disk s konstantní dobou zápisu. (Samosebou by na něj nikdo nesměl zapisovat komprimovaný soubory, nebo jiný podivný soubory, který obsahujou nějakou informaci. Ale kdo by to dělat, že jo :) ) No nebylo by to senzační? Už vidím ty headlajny... Mějte se, běžím podat patent :)
Pokud vím, všechny supercool features supernového formátu od Microsoftu obsahuje už i Btrfs. ReFS vnímám jen jako další produkt Microsoftu pro snížení funkčnosti ostatních systémů (nekompatibilitou); a o okradení FOSS vývojářů o tisíce hodin při pokusech o reverse engineering. Microsoft si NEDÁ pokoj. Pfff.
Podla mna v tomto pripade ide o cisty pragmatizmus. Hlavnym dovodom bude asi to, ze ich terajsi NTFS kod je totalny bloatware, ktory uz asi nema nikto sancu upratat a pravdepodobne im robi velke problemy pri portacii na ARM, aj celkovo ine platformy, kde je dolezita spotreba. Proste sa rozhodli naimplementovat nieco dost podobne, ale od zaciatku s tym, ze vyhadzu vacsinu veci, ktore pokladaju za nepotrebne (a mozno ich casom opat budu pridavat) a zameraju sa na to, aby to aspon nejako bezalo, bolo to ich a mohli to zacat rychlo pouzivat.
A druhy dovod je urcite aj to, ze si mozu dat dalsiu fajku do zoznamu, precu su najlepsi a patricne to vyuzit v reklame.
Souhlasim.
Pak jde taky o to ze SIFROVANI i KOMPRESE nemaji byt soucasti samotne implementace FS, ale maji se resit na vrste o uroven vys (bud v mezivrstve, nebo aplikacne). (A podobne to plati o RAID rezimech.. nektere FS se je snazi integrovat do sebe).
Docela se divim ze btrfs se vydava cestou all-in-one, vsak take muze dopadnout jak reiserfs.. s neduverou kvuli nestabilite (zpusobenou slozitym kodem). A prekvapuje me ze vyvojari puvodne uznavajici jednoduche principy musi zas nacpat vse dohromady, namisto vytvoreni jasnych atomickych modulu s trvacnym rozhranim..
To bude z toho důvodu, že šifrování, komprese i RAID řešený někde výše/níže nikdy nebude tak účinný, jako když to řeší přímo souborový systém (třeba řešení silent corruption pomocí checksumů, mirrorování často používaných dat na RAID-5, deduplikace ap.). Správně by to tedy měl řešit tak, že ta data pošle nějaké (externí) funkci, která je zašifruje/zkomprimuje/zaRAIDuje, a potom ta hotová data zapíše. Tedy přesně tak, jak to Raiser4 nedělal a proto dopadl, jak dopadl.