Vlákno názorů k článku
Ext4 přijde o volbu data=journal od Ondrej Nemecek - Logiku v tom odstranění nevidím. Pokud to chápu...

Logiku v tom odstranění nevidím. Pokud to chápu dobře, je to nejpomalejší - zato nejbezpečnější, což je ale očekávatelné chování, ne?

Tak to bude teď označené jako zastaralé a ti co to používají (moc jich nebude) se budou moci vyjádřit.

Komu opravdu záleží na datech, tak stejně používá FS s COW a kontrolním součtem souborů, ne EXT4.

Btw, jak se pozná, kolik jich je?

spočítá se počet stížností v LKML?

Takhle to opravdu standardně probíhá? Čekal bych něco jako předchozí diskuzi, ne diskuzi až jako reakci na deprecation označení.

A jak ta diskuze asi jako začne jen tak z ničeho?

Jestli myslíte, že zrovna scream test je optimální začátek diskuse o nějaké funkci, tak nevím, no.

Ta bezpecnost je relativni a zalezi na implementaci disku - zda dodrzuje striktne sekvence, nebo ne. V dobe rotacnich a NCQ disku se sekvence prave rozbijela, v dobe SSD pochybuji ze nejaky disk by resil frontu out-of-order.

Takze souhlasim s tvurci ze zurnalovani dat je blbost v dnesni dobe - delate 2x vice IO vcetne extremniho seeku takze ten vykon by sel dolu nasobne.

Kdo chce "zurnalovana" data tak pouziva COW.

Volba EXT4 s tuningem dnes neni kvuli bezpecnosti dat, ale prave bez tuningu, kvuli rychlosti. Kdo se zajima o bezpecnost dat, ten se nespokoji s pouhym resenim orderingu zapisu a bude dbat i na checksumy bloku - coz EXT nikdy neresil bohuzel.

Za me tady OK (a to jsem veliky kritik zmen v jadre).

Na tohle konkrétně nemám názor, ale uplatňujete typické technické "buď všechno nebo nic". Jenomže v realitě chcete nějakou míru spolehlivosti, nepotřebujete absolutní ve smyslu COW a řešit relativně méně běžné file systémy ale zároveň asi s dnešními vyrovnávacími paměťmi nechcete jet jen stylem v případě výpadku padni komu padni. A fakt nejde o servery ale o obyčejné desktopy.

Takže ne, není to blbost. Je to prostě nějaká baseline.

V principu ano, na druhou stranu si říkám, jaký use case ten žurnál pro data má – jestli se to spíš v praxi neřeší na aplikační úrovni.

Jenže tahle konkrétní "baseline" není default, takže to není ani žádná baseline.

Právě:

1. V mnoha případech to bude overkill – když budu stahovat soubor ve Firefoxu, vytvoří dva soubory (placeholder a soubor se skutečnými daty), po dostahování nahradí placeholder se souborem se skutečnými daty. Mít k tomu data=journal znamená více zápisů (a opotřebení flash paměti), aniž by to mělo přínos.
2. Často je to na úrovni FS vlastně málo – ještě bychom potřebovali zajistit, aby nějaká množina zápisů byla atomická.
3. I pokud náhodou data=journal dělá přesně to, co by aplikace potřebovala, je použití omezené i tím, že by bylo potřeba zajistit, že je ten parametr nastaven. Možná při nějakém specifickém použití (např. autor aplikace zajistí i provoz na specifické konfiguraci), možná analýzou mount options. A pokud mount options nebudou sedět, aplikace by odmítla fungovat, nebo by musela mít stejně kód, který to bude řešit.

A když nad tím přemýšlím, nenapadá mě reálný use case pro #3. Spíše data=journal bude dělat moc (#1) nebo málo (#2 – a paradoxně i zde jde o zvýšení overheadu, když žurnáluju dvakrát).

Další věci jsou otázky portability kódu (i na jiné FS, nejen na jiné OS), přínosu (ani při hypotetickém use case pro #3/nečekám zásadně vyšší výkon), nákladů na vývoj a testování (při hypotetickém use case pro #3 dost možná budu potřebovat ošetřit i situace, kdy se na data=journal spolehnout nemůžu).