S dovolením si myslím, že je fajn, že Linux nějaké chyby umí rozpoznat a přečíst soubory i přesto. Samozřejmě by v takovém případě asi měl do dmesg vypsat nějakou rozumnou chybovou hlášku. Jistě ale jsou případy, kdy prostě není možné novější firmware nahrát a potom jakoby nějak soubory přeuložit nebo co. Prostě máte kartu, na ní data a nějak to chcete přečíst. Windows to nejspíš nějak přečtou, tak by bylo fajn, kdyby Linux na problém upozornil ale data pokud možno přečetl a systém volitelně např. opravil.
Je super, když má systém nějaký jasný hlavní strom, který je jakoby čistý a podle specifikace. Je ale hodně praktické, když má nějak zřetelně (např. komentářem) označené části pro lepší kompatibilitu s realitou, která prostě nikdy není perfektní.
Další věc je, že někdy např. specifikace nebo standard jsou psané dostatečně debilně, takže prakticky zaměřený člověk například chce nebo dokonce musí přidat další předpoklady, nebo omezení, aby vůbec byl s věcmi hotový. Ono totiž hodně lidí myslí především na to, jak práci a zodpovědnost delegovat, místo na to, jak by mohli svoji část udělat dobře, aby jiní měli práce a zodpovědnosti méně.
Zrovna v poslední době jsem řešil třeba čtení a zápis cookies, což je prostě tragédie. Autoři RFC nechali zbytečně moc volnosti a implementace v prohlížečích je taky dost laxní. Kdyby to člověk chtěl psát opravdu dobře, musel by si na to napsat vyloženě parser. Žádná z implementací, co jsem viděl se s tím ale takhle rozhodně necrcá a naférovku třeba dělí podle středníku a rovnítka. K RFC jsem neviděl nějakou oficiální implementaci, protože to by asi autorům ruce upadly něco takového napsat.
Jo, alespoň záznam do dmesg by to chtelo. Tyhle "tiché opravy" jsou zlo...mi se jednou povedlo takhle potichu "vymazat" SD kartu. Vložil jsem ji nevědomky do čtečky, která uměla max 32GB, ale karta měla 64GB. Normálně jsem ji v Linuxu připojil, ale po chvilce se začala chovat divně, tak jsem ji odpojil a zkusil vrátit zpět do telefonu. Jaké bylo mé překvapení, když partition i FS hlásily najednou jen 32GB a většina adresářů byla fuč (po prozkoumání byly soubory za hranicí 32GB "vymazané"). Chtěl jsem to ohlásit jako bug, ale nepodařilo se mi to už zreplikovat a ani v logách nic, tak jsem se na to vykašlal. Dodnes nevím, jestli to je nějaká vlastnost v jádře, že zlikviduje data která jsou za koncem zařízení, nebo to sestřelila ta čtečka (i když ta by na FS neměla šahat, je to jen převodník sd-usb).
Pokud byly tyto převodníky uvedeny na trh někdy v době, kdy již existovaly SATA disky > 2 TB a pokud nebyly explicitně označené/ dodávané jen pro disky < 2 TB, tak je to další případ "engineeringu", za který by bylo dobře fackovat.
Naštěstí se dá snad tohle chování před prvním použitím ověřit tak, že se do sektorů kolem začátku testovacího, tedy prázdného disku napíšou nuly. Potom se začne psát těsně za 2 TB. Potom se vyčtou předtím zapsané nulové sektory a pokud obsahují něco jiného, než nuly, tak tam ten wrap je.
Něco na tenhle způsob by mělo stačit:
diff <(dd if=/dev/zero count=1) <(dd if=/dev/random count=1)
To vypíše, že se obsahy liší a návratová hodnota echo $? je 1. Když porovnám /dev/zero se sebou samým, tak se (očividně) nic neliší a návratová hodnota je 0.
Jsou to převodníky recyklované z vysloužilých externích disků, jednu dobu jsem to kupoval po pytlích z různých e-waste firem (např.). Dělal jsem z toho mikro NASy (NanoPi s ethernetem a USB za $15, tenhle převodník za $2, a k tomu třeba 500G disk taky z e-waste). Máme takhle s kamarády různě po světě distribuované úložiště.
Jasně no, takže v podstatě na 2 TB+ disky ty převodníky prostě nebyly designované, protože to nejspíš nebyl požadavek. Můžu se zeptat, jak řešíte to distribuované úložiště? Je to glorifikovaná sada rsync skriptů, Syncthing nebo se to tváří víc jako jeden celek a mluví to nějakým API?
7. 7. 2021, 12:57 editováno autorem komentáře
Podle meho nazoru to je cesta do pekel, toto by mel resit userland. Treba skrze hlasku, ze pripojujete nezkontrolovany/poskozeny filesystem, chcete opravit? A u toho zobrazit zpravu, ze nejspis jde o poskozene adresare vadnym firmware, zda u nich chce soubory obnovit nebo brat delku streamu tak jak je.
Patch jsem nestudoval dusledne, ale umim si predstavit, ze nekdo te delky streamu zase vyuzije opacne ... a je na svete problem.
Bohuzel mount nema pre-check, chybu kontroluje az fs driver v kernelu. Takze v pripade poskozenych struktur by to spis melo fungovat takto:
mount - projde
cd, ls - funguje dokud to nenatrefi na spatnej dir
spatnej dir - nastavi priznak unclean a vykopne to disk - umount
user zkusi mount znova - a to uz mu neprojde
(bohuzel error je zas jen v dmesg, mount konci jen s tim ze to nejde)
Jako urcite by to chtelo nejaky option na error handling, at se da menit strategie:
* tise opravovat (jako tento patch)
* chyby fs ignorovat / vypisovat
* na chybe fs rovnou zastavit