Portál AbcLinuxu, 6. května 2025 23:16
Řešení dotazu:
14.8.2022 08:52
Jendа | skóre: 78
| blog: Jenda
| JO70FB
…a tam vždycky rsyncnu zálohu…
Chyba; rsync není atomická záloha a navíc ještě vyhazuje oknem ven všechny výhody snapshotů a s nimi související deduplikace. rsync pro zálohy dává (částečně) smysl jedině s read-only zdrojem — a jen při velmi liberální definici pojmu „dávat smysl“.
…a udělám snapshot.
Nesprávné pořadí kroků vede k porušení atomicity a k plýtvání prostorem. Správný postup je
btrfs send ... vytvořit „rozdílový stream“ proti minulému zálohovacímu snapshotu,btrfs receive ... vytvořit další snapshot odkazující se na předchozí cílový snapshot.Takový postup (0) zachovává vždy všechny atributy souborů a adresářů, současné i budoucí, i takové, které rsync nezná, (1) zachovává atomicitu zdroje i cíle, (2) neduplikuje už zálohované a nezměněné bloky a (3) přenáší / kopíruje jen to, co je třeba.
Skvělé taky je, že pro úsporu místa na zdroji stačí udržovat jen jeden (předchozí) snapshot, aby inkrementální zálohování fungovalo. Cíl (u kterého se předpokládá větší kapacita) může držet víc snapshotů, chce-li, a ty historické třeba postupně „ředit v čase“ na základě nějakých kritérií (například: (0) chci mít snapshot starý aspoň takhle, (1) chci mít nanejvýš tolik snapshotů a (2) chci, aby rozdělení stáří snapshotů bylo „exponenciální“ nebo podobné; nejnovější budou nejhustší, starší budou řídnout — tohle už se dá snadno naskriptovat).
Cokoliv jiného je asi jako petrolejka v éře LED.
Co bych měl popsat? Udělat Copy&Paste něčeho z man btrfs-send a man btrfs-receive? To podle mě nemá smysl dávat do blogu. (Kromě toho nejde o nic nového; tenhle princip má svou dlouhou historii už od dob ZFS, tj. minimálně desetiletí a půl zpátky.)
Je mnoho lidí, kteří ještě nezálohují a tak doufám, že tento návod to pomůže změnit.Tak kdyby existoval ještě nějaký XUI program se všemi možnostmi. Naposledy jsem "snapshotoval" v ranných verzích yast2-snapper, to umělo jen vytvářet snímky a to ještě tak že tak že si činnost uzurpovala téměř 3/4 výkonu PC.
30.8.2022 08:59
Petr Tomášek | skóre: 39
| blog: Vejšplechty
navíc ještě vyhazuje oknem ven všechny výhody snapshotů a s nimi související deduplikaceHovadina. Rsync a snapshoty se dají výborně kombinovat. Jsi nikdy neslyšel of rsync -c --inplace --no-whole-files ?
rsync a snapshoty se dají kombinovat podobně jako mléko s citrónovou šťávou. Jasně, dají se kombinovat, ale ta kombinace je na řídké hovno. 
Dál bych podotkl, že --inplace --no-whole-file v tomto kontextu není velká výhra: Nepomáhá s efektivitou v tom smyslu, aby se od minula nezměněné bloky vůbec nemusely číst (natož přenášet a zapisovat).
Stating the obvious, --inplace má asi tak všechny myslitelné nešvary, jaké si u špatného zálohování lze představit — problémy s atomicitou všude kolem, spousty okrajových případů s nekonzistentním výsledkem atd. Manuálová stránka nabízí u --inplace obsáhlé počtení k těmto chmurným tématům.
Zálohování pomocí atomických snapshotů nad CoW filesystémem a k nim příslušných send / receive příkazů žádnou takovou↑ spleť problémů nemá.
…jestli lze nějak vyzkoušet možnosti BTRFS na externím plotnovém usb disku…
Nebo musím mít / naformátovaný bezpodmínečně také na BTRFS?
Inu, záleží na tom, co přesně chceš vyzkoušet. (Mimochodem, víc než dekádou prověřený a velkými distribucemi doporučený souborový systém Btrfs není třeba nějak zkoušet; stačí ho zkrátka normálně používat. Just sayin’.)
Samozřejmě lze vyzkoušet Btrfs na kterémkoliv jednotlivém blokovém zařízení. Třeba na loopback souboru nad Ext4 fosilií. 
Nebo na loopback souboru nad ramdiskem (tmpfs); proč ne, moc trvanlivé to sice nebude, ale na bleskově rychlé experimenty se to skvěle hodí. Nebo na plotnovém USB disku. Nebo na Thunderbolt SSD. Nebo na SD kartě, na USB flashdisku atd. atp… Všude se hodí Btrfs.
Jenže: Pokud chceš naplno využít všechny výhody Btrfs, a zejména jednu z jeho killer features — atomické inkrementální zálohování pomocí zdrojových a cílových snapshotů a btrfs send / receive —, v takovém případě je potřeba mít Btrfs na „zdroji“ i na „cíli“ záloh. Jinak bude případné zálohování vypadat (jak už jsem psal v jiném komentáři) jako petrolejka v éře LED.
30.8.2022 09:14
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Prdlajs. Jak přesně opraví ten zázračný Ext4 fsck posraná data, u kterých nemá checksum ani redundanci??? Btrfs je buď obnoví z kopií, nebo zkrátka upřímně řekne, že jsou pryč. Ext4 ti bude servírovat náhodné kraviny.
Btrfs je nesrovnatelně spolehlivější, protože zaprvé poskytuje vestavěnou redundanci, chce-li ji uživatel (na jednom zařízení i přes několik zařízení), a zadruhé má checksumy dat, ne pouze metadat.
Když se posere hardware, na kterém je Btrfs — v drtivé většině případů tedy ne Btrfs jako takový —, dozvíš se o tom, což je klíčové.
Ext4 máš posraný už teď, bit sem, bit tam, nám už je to všechno jedno — jen o tom nevíš a dozvíš se to, až jednou ty poškozené soubory budeš potřebovat. Jenže poničená data už budou zkopírovaná i do všech záloh — pozdě brka honit.
Sorry jako, ale tohle téma se tu už řešilo tolikrát, že i hodně hloupí FUDisté si už musí připadat hloupě. Nevím, jak to říct diplomaticky.
Recovery nástroje pro získání „aspoň něčeho“ z disku sejmutého kladivem pro Btrfs samozřejmě jsou — jen si nebudou hrát na to, že z příslušného guláše vykouzlí konzistentní filesystém. V takové situaci to vůbec nedává smysl.
1.9.2022 12:30
Petr Tomášek | skóre: 39
| blog: Vejšplechty
a ze si nepripadas hloupe ty, v minimalne tom jednom reseni sem psal sve zkusenosti s BTRFS kdy 2 z 2 pokusu o jeho nasazeni skoncily do tydne zkolabovanim BTRFS a nepomohlo zadny z jeho opravnych nastroju... a take to ze s EXT4 naopak sem na zadnej problem za 10let a nasazeni na XY disku ci mdadm poli nenarazil... toz ti preju dalsi tve arogantni a napul lzive komentare kterejma budes v tom kolobehu pokracovatSorry jako, ale tohle téma se tu už řešilo tolikrát, že i hodně hloupí FUDisté si už musí připadat hloupě. Nevím, jak to říct diplomaticky.
Ten bájný pokus o nasazení Btrfs se odehrál na zcela novém a bezproblémovém hardwaru, kvalitou srovnatelném s tím, na jakém běžely (údajně) bez problémů jmenované fosilie? (Údajných 10 let bez problémů nelze bez atomických checksumů dat nijak doložit, tudíž jde všeho všudy o zbožné přání.)
Nebo je to opět ta ohraná písnička na téma "zkoušení" Btrfs na starém vyřazeném hardwaru a divení se, že ten hardware není v pořádku a že si toho Btrfs všimne?
K těm údajným kolapsům Btrfs bych si moc rád přečetl příslušné bug reporty. Jistě jsou zajímavé a poučné. Odkazy by byly?
k raid1, dup ani snapshot sem se ani nedostal, jen format, vytvoreni subvolume, rsync dat a po rebootu nikde
11.9.2022 00:53
Jendа | skóre: 78
| blog: Jenda
| JO70FB
30.8.2022 09:11
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Ta killer feature se nejmenuje fragmentace, nýbrž mount -o autodefrag.
Další FUDista se spletl.
31.8.2022 09:16
Petr Tomášek | skóre: 39
| blog: Vejšplechty
31.8.2022 16:50
Petr Tomášek | skóre: 39
| blog: Vejšplechty
.
Takže si nevybereš, o to jde.
Maximálně, co můžeš zkusit, je nastavit NOCOW, ale pak už je skoro lepší jakýkoliv NOCOW-filesystem... jako např. ext4...
. Koupil jsem si tedy 1TB ssd opět Samsung, fs mám ext4 a TBW naprosto v pohodě.
Na disku jsem mimo velikých databází nic podstatného neměl a nepoužíval.
Co kdyby ses tak trochu rozepsal o jaký typ databáze šlo? Brfs nad SSD totiž není pro některé zrovna optimální FS. A pokud jde o ext4. TWB můžeš mít v pohodě a zároveň data v háji aniž bys měl tušení. A jsou databáze, co mají mechanismy, které brání aby k tomu došlo, jenže u COW souborových systémů, co běží na SSD, kde mají buňky limitovaný počet zápisů ti to může utavit disk, pokud je na to sám.
24.8.2022 16:36
k3dAR | skóre: 63
Jak jsem psal výše na novém disku již pokusničit a riskovat nebudu. S TBW na ext4 jsem naprosto spokojený bez jakéhokoli nastavování. Měl jsem se držet starého dobrého "co funguje neměnit a nevrtat se v tom". Stálo mě to ssd disk a mohu si za to sám.
"co funguje neměnit a nevrtat se v tom"
Jenže Ext4 nefunguje. Odtamtud dál ja pak už celá úvaha špatně.
30.8.2022 09:15
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Ext4 funguje 100x spolehlivěji než btrfs...
Solidní statistiky k tomuto↑ debilnímu žvástu najdu kde přesně???
Ext4 je předpotopní nespolehlivý FS z dob 10GB disků, kdy se disky považovaly za spolehlivé a tak celkově se spoléhalo na zázraky. Btrfs je nesrovnatelně spolehlivější, zhruba ve smyslu 1 – pravděpodobnost chyby disku krát pravděpodobnost kolize checksumu.
Smiřte se s tím, zoufalí zapšklí FUDisté. Takhle to prostě je. Takhle ten dnešní svět funguje, víme???
30.8.2022 23:54
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Btrfs je nesrovnatelně spolehlivější, zhruba ve smyslu 1 – pravděpodobnost chyby disku krát pravděpodobnost kolize checksumu.Ano, protože chyby v datech co vrátí disk jsou jediné chyby které se v počítačích objevují.
31.8.2022 09:14
Petr Tomášek | skóre: 39
| blog: Vejšplechty
31.8.2022 17:38
Jendа | skóre: 78
| blog: Jenda
| JO70FB
modprobe irony(nežereš ovoce, nepoznáš vtip :D)
31.8.2022 18:54
Petr Tomášek | skóre: 39
| blog: Vejšplechty
31.8.2022 09:12
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Reakce na tenhle FUD, která se kvůli (už cca rok otravujícímu) bugu v ABCLinuxu nedá vložit do vlákna, kam patří…:
Obrovský objem zápisů, způsobený nejspíš tím, že si uživatel něco špatně nakonfiguroval a to něco pak psalo a psalo — můžeme hádat, který validator node to asi byl , se tady nesmyslně svádí na souborový systém.
Mimochodem, proč je jisté, že to „způsobil“ Btrfs a nikoliv třeba (omylem použitý) swap na SSD? Nebo to není až tak jisté…?
Tohle je asi jako: „Měl jsem Rolls-Royce, ale řídil jsem ho ožralý a naboural jsem se do stromu. Tak už jsem vyléčený z takových nápadů — Rolls-Royce už nikdy více. Budu řídit Trabant! S Trabantem se mi rozhodně nemůže stát totéž!“
Otázka je, jaká je asi motivace těchto anonymních FUDistů. Cui prodest?
Na niečo je vhodný EXT4, na niečo iné BTRFS alebo ZFS, či nebodaj SquashFS alebo GlustreFS.Mícháš jabka s hruškama. Swap má svoje opodstatnění, když víš co a proč děláš. Pro mne je to bezpečnostní pojistka. Swapuje se jen když paměť nestačí, takže když swapování začne a mám něco rozdělané, mohu ještě něco řešit. Bez swapu bych byl namydlený, protože 128GB RAM v notesu nemám.
Mícháš jabka s hruškama.Hrušky by som kedával zapiecť ku kačici, jablká áno.
Swap má svoje opodstatnění, když víš co a proč děláš.Swap som v posledných rokoch používal len na hibernáciu. Ak už systém zletí do swapu, tak je počítač na môj vkus pomalý.
Bez swapu bych byl namydlený, protože 128GB RAM v notesu nemám.Nechávať si v notebooku 128GB RAM na swap je aj na môj vkus trošku veľa. Ale asi som divný.
Vše co jsem uvedl v prvním příspěvku je moje zkušenost nic více nic méně. Možná to tazatele přiměje k tomu aby si nevýhody tohoto fs ověřil.Vytáhnout z vás informaci, co jste provozoval na tom jednom disku, kde jste měl btrfs a který vám odešel, dalo spoustu práce a ještě si nemůžeme být jisti, že jste napsal všechno, natož pak podrobně. Lezo to z vás, jak z chlupaté deky. Takže je těžké brát vaši zkušenost za bernou minci pro rozhodování, jestli btrfs ano nebo ne.
Dokonalé. Naprosto přesně jak jsem psal:
„Řídil jsem ožralý Rolls-Royce a nabořil jsem se s ním do stromu. Proto odteď řídím Trabant. Rolls-Royce už do mých rukou nesmí!“
Inu, hodně štěstí s postupně mizejícími daty na předpotopních FS typu Ext4. Dvě věci jsou nekonečné, že ano…
Inu, hodně štěstí s postupně mizejícími daty na předpotopních FS typu Ext4.Tím už tady vyhrožujete léta, ale zatím tu víc lidem zmizela data na tom moderním a skvělém BTRFS...
Komu? Kde? Kdy? Na jakém přesně hardwaru? (Novém?) V jakém experimentu / srovnání? Který jiný FS (by) ustál totožnou situaci?
Fakta? Čísla? Kde jsou?
Hele, FUD je zkrátka na hovno. FUD má holou prdel.
Ještě tak v roce 2012 by tohle bylo snad i vtipné (s jízlivým úsměvem typu „no tak to nepoužívej, když nechceš; ona to použije schopnější konkurence“). Nicméně roce 2022 … nevím, no. Asi někdo příliš dlouho hibernoval.
Takže fakta a čísla nejsou.
Děkuji za potvrzení. Klasika. Jako vždy.
Už se těším na další perly typu "vytáhl jsem ze sklepa 15 let starý notebook, dal jsem na něj 'na vyzkoušení' Btrfs a světe div se, on se mi tam objevil checksum error". Pořád ta samá hloupá písnička.
Děkuji za potvrzení. Klasika. Jako vždy.Nemáte zač, tu klasiku jako vždy, kde ignorujete realitu a nahrazujete ji svou vlastní, jste tady napsal sám.
df.
Ale tohle všechno je dávno pryč. Používám už více než 10 let btrfs všude. Na nvme, SSD i rotačních discích. Důležitá data v RAID 1 a mnoho nedůležitých dat na singl discích. Celkem tak přes 40TB na cca 10 rotačních discích. Vzhledem k tomu, že pravidelně měsičně btrfs provádí scrub testy, tak vím, jak data na těch discích jsou. A mohu ti potvrdit, že chyby check sumu se objevují. Pokud se začnou objevovat více, tak disk se posune u mne do pozice nedůvěryhodného a jsou na něm jen data, které mi nevadí, že o ně přijdu. Znamenají jen nějaké opětovné stažení z netu. A celkem za ty léta jsem na základě btrfs scrubu vyřadil již 4 disky. A teď už mi asi odchází 8TB WD green, který ve scrubu má každy měsíc jednotky chyb. (a samozřejmě zjistíš v jakých souborech ty chyby jsou a když je to btrfs RAID1 tak je chyba opravena) Jinde tu kontrolu nemáš. Max můžeš disk přečíst a to zjistíš jen read error a ne špatný checksum. Takže to, že z např. ext4 nikdo nereportuje ztrátu dat může být jen to, že na ni nepřišel.
31.8.2022 21:15
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Vzhledem k tomu, že pravidelně měsičně btrfs provádí scrub testy, tak vím, jak data na těch discích jsou.Fun fact: scrub nekontroluje strukturu filesystému ("fsck"), chyby na tebe vypadnou klidně až když se nějaký soubor pokusíš opravdu přečíst. Každopádně je super že jsi na tohle narazil -- zkoušel jsi zkoumat jak to vypadá? Je v tom sektoru pár bitflipů, mění se to když to přečteš po power cycle, jsou tam samé nuly…?
[265079.706162] BTRFS warning (device dm-7): checksum error at logical 26544592297984 on dev /dev/mapper/miraza, physical 230671491072, root 5, inode 5670856, offset 189988864, length 4096, links 1 (path: hudba/pracovni/Beethoven_Piano Concertos - Maurizio Pollini, Claudio Abbado & BPO [2021 Esoteric]/No.1 & 2/04 - 1. Allegro con brio [Piano Concerto No.2 in B flat major, O.dsf)Je to na RAID1 takže bez problémů byla korekce.
/dev/mapper/miraza je LUKS šifrovaný disk zaraženy do RAID 1 poolu. Co skutečně se stalo na fyzickém disku, když po dešifrování předalo do filesystému checksum chybu nemám chuť zkoumat. Ten fyzický disk se pro mne tím pádem posouvá do kategorie "na výměnu". (On na to již má nárok. Je to totiž tento disk.)
smartctl -a /dev/sde
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.19.4-zen1-1-zen] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F2 EG
Device Model: SAMSUNG HD154UI
Serial Number: S1Y6J1LS806866
LU WWN Device Id: 5 0024e9 001feff7a
Firmware Version: 1AG01118
User Capacity: 1 500 301 910 016 bytes [1,50 TB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database 7.3/5319
ATA Version is: ATA/ATAPI-7, ATA8-ACS T13/1699-D revision 3b
Local Time is: Thu Sep 1 13:21:31 2022 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (19143) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 320) minutes.
Conveyance self-test routine
recommended polling time: ( 33) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 099 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 071 071 011 Pre-fail Always - 9430
4 Start_Stop_Count 0x0032 098 098 000 Old_age Always - 1841
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 091 015 Pre-fail Offline - 11670
9 Power_On_Hours 0x0032 086 086 000 Old_age Always - 73068
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 1537
13 Read_Soft_Error_Rate 0x000e 100 099 000 Old_age Always - 0
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0033 001 001 000 Pre-fail Always - 300
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 4
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 068 033 000 Old_age Always - 32 (Min/Max 15/35)
194 Temperature_Celsius 0x0022 068 032 000 Old_age Always - 32 (135 207 36 15 0)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 928398662
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 1141
200 Multi_Zone_Error_Rate 0x000a 100 099 000 Old_age Always - 1
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 6291 -
# 2 Extended offline Completed without error 00% 2239 -
# 3 Extended offline Completed without error 00% 61821 -
# 4 Extended offline Completed without error 00% 61101 -
# 5 Extended offline Completed without error 00% 60709 -
# 6 Extended offline Completed without error 00% 53925 -
# 7 Offline Completed without error 00% 52465 -
S nájezdem přes 73 000 hodin patří k mým nejstarším. Je zajímavé, že testy ani nepočítaly s tak vysokám nájezdem a přetočilo se jim 16 bitové numero. Poděkuji mu za dlouholeté věrné služby a vyměním ho v poli za novější disk. Vzhledem k flexibilitě souborového btrfs RAID1. tak třeba za něco takového jako Toshiba od Mironetu.
/dev/mapper/miraza je LUKS šifrovaný disk zařazený do RAID 1 poolu." a "..testy ani nepočítaly s tak vysokým nájezdem..."
btrfs scrub status /mnt/archiv UUID: d1722103-0c1e-4627-bbc7-9f1f0bf91739 Scrub started: Thu Sep 1 00:00:47 2022 Status: finished Duration: 13:23:40 Total to scrub: 14.99TiB Rate: 325.90MiB/s Error summary: csum=1 Corrected: 1 Uncorrectable: 0 Unverified: 0pomocí nichž si zkontroluji, jak scrub dopadl.
Co skutečně se stalo na fyzickém disku, když po dešifrování předalo do filesystému checksum chybu nemám chuť zkoumat.Ale s jistotou víte, že to byla chyba disku a ne chyba filesystému... Protože tohle je na btrfs to nejzajímavější. Lidi tvrdí, jak jim scrub odhaluje jednu chybu za druhou. Dobrá, disky jsou nespolehlivé, vrací chybná data. Jak je možné, že jsem za ty roky nenarazil na něco, co by bylo rozbité? Špatně přečtený program bude dělat kraviny nebo padat, pokažený soubor nepůjde otevřít nebo bude obsahovat nesmysly... a ani na jedno z toho jsem ještě nenarazil. Při kopírování dat mezi disky dělám sha256sum na všechny přenesené soubory a vždycky všechno v pořádku. Před zálohováním dělám checksum souborů v záloze proti aktuálnímu stavu a vždycky všechno v pořádku. Jako uznávám, že tam samozřejmě patří slovo zatím, ale podle toho, co tady nejen vy píšete, tak mě dávno měla postihnout totální apokalypsa.
find / -type f | wc -l jelo 15 minut a nahlásilo něco přes 7 milionů souborů. Tahat si v desítkách tisiců adresářů soubory s hashy těch ostatních, nebo vytvářet nějaké jiné struktury mi připadá moc komplikované. (Systémová část etc,bin,usr,boot je samozřejmě hashovaná a kontrolovaná ještě přes rkhunter, ale to nejsou TB uživatelských dat.) Souborový systém s check sum integritu zařídí. Čistě pro ilustraci celkový součet obsazeného prostoru připojených souborových systémů na pracovní stanici, reportovaných df má 29831724820 kilobytových bloků (podle du -s 27703041088). Tedy málo přes 30TB obsazeno, 28TB skutečná data. (to 14TB pole z úvodu je v df jako 7337884672 obsazené bloky, protože je to RAID1). Chyby se mi objevují, je jich celkem málo, scrub mi umožňuje je mít pod kontrolou a vědět, kde nastávají. To je vše. Zase na rozdíl od jiných zpráv, jak btrfs havaruje se mi tohle nikdy nestalo, že by se nabourala struktura FS (nebo možná někdy před více než 10 lety) a spolehlivě ustál i několik mých silných chyb, jako třeba vypnutí prodlužky, když systém prováděl "poweroff", ale nevšiml jsem si, že ještě není dokončen, nebo vytržení externího disku během zápisu na něj.
A jsem v poslední době (cca 2 roky) i velmi spokojen s rychlostí btrfs, významně se zvýšila, jak přímá rychlost FS tak i úklidové operace, tedy když z FS překopírují několik set GB jinam, tak úklid b-stromů a opětovné získání a reportování prostoru na FS, je velmi rychlé.
A mohu ti potvrdit, že chyby check sumu se objevují. Pokud se začnou objevovat vícea teď:
co jsem napsal, že se mi objevila jedna chybaa pak zase:
Chyby se mi objevují, je jich celkem máloTak jak to teda je? Objevila se vám jedna chyba, víc chyb, málo chyb...? Vyberte si. Já jsem každopádně reagoval na to první, co jste napsal: že se vám chyby objevují. Tak proč mně ne?
Tahat si v desítkách tisiců adresářů soubory s hashyOd toho mám počítač, aby dělal repetetivní úkoly za mě. Aale / teda fakt neřeším, kdyby něco, tak tam jsou k dispozici nepoškozené zálohy v distribučním archivu balíků.
Od toho mám počítač, aby dělal repetetivní úkoly za mě. Aale / teda fakt neřeším, kdyby něco, tak tam jsou k dispozici nepoškozené zálohy v distribučním archivu balíků.Ale přece o zálohu systému vůbec nejde. Záloha systému včetně snapshotů na btrfs před a po aktualizaci se tohoto vůbec netýká. To proč se Vam neobjevují je Váš use case, třeba nemáte tolik dat, nečtete je pravidelně všechny, jsou v oblasti která není podstatná, chyba v multimedálním souboru někde uvnitř se může projevit i jen nepříliš výraznou změnou, zvláště když není na šifrovaných discích. Pak se bit flip jen projeví jako jednobitová změna a není blokovou šifrou roznesena do celého sektoru. Ale to není můj case.
No za asi 8 let stabilního používání se chyb odhadem objevilo tak cca 50-80No a to je ta apokalypsa, o které mluvím. Jestli vám za 8 let scrub našel 50-80 chyb, tak jaktože já jsem za tu dobu nenarazil na jediný chybný dokument, na jediný kravnoucí program, který by se přeinstaloval stejnou verzí a začal znovu fungovat, atd.
Ale přece o zálohu systému vůbec nejde.Čtěte si to v kontextu. Reagoval jsem na vaši reakci na počítání checksumů před zálohováním, že máte v / miliony souborů - a já říkám, že kolik souborů mám v / mě vůbec nezajímá, protože když se nějaký poškodí, tak ho stáhnu znovu, tudíž nemusím řešit ani poškození, ani checksumy, ani zálohy. A ty počítám jen pro dokumenty, tj. /home apod.
…tak jaktože já jsem za tu dobu nenarazil na jediný chybný dokument, na jediný kravnoucí program, který by se přeinstaloval stejnou verzí a začal znovu fungovat, atd.
Nic z tohoto↑ nelze s jistotou tvrdit ani vědět, takže jsou to všeho všudy kecy plus doufání v zázrak.
Jak se pozná, že binárka není poškozená, když FS nemá checksumy?
Proč by poškozená binárka musela nutně spadnout? Co když je poškozená tak, že nespadne, ale bude třeba zapisovat nebo odesílat nesmysly nebo přidávat šum do ukládaných médií?
…protože když se nějaký poškodí, tak ho stáhnu znovu…
Manuálně? Opravdu zaručeně a pokaždé? Kdy přesně? Jak se to poškození spolehlivě pozná? Kouzelnou hůlkou? Nebo křišťálovou koulí?
…tudíž nemusím řešit ani poškození, ani checksumy…
Tady↑ máme neporozumění realitě, Level Ultimate. Tohle snad ani není možné. Asi to bylo míněno jako vtip / recese / trolling.
A ty počítám jen pro dokumenty, tj. /home apod.
Jak je zaručená atomicita takových (téměř) manuálních rádoby-checksumů? Jak přesně jsou dokumenty chráněné mezi časem změny a časem aktualizace checksumu? A především: Proč vůbec explicitně a téměř manuálně dělat cosi navíc, co má dělat filesystém?
Sorry jako, ale tyhlety pseudoargumenty (stejně jako celý anti-Btrfs FUD) mají zkrátka holou prdel, jak už jsem psal výše.
Nic z tohoto↑ nelze s jistotou tvrdit ani vědětVy možná nedokážete rozpoznat, že dokument nelze otevřít, že obsahuje nesmysly nebo že program nefunguje, ale je mnoho lidí - odvažoval bych se říct, že většina - kteří to dokáží. Učte se, třeba to jednou zvládnete taky.
Jak přesně jsou dokumenty chráněné mezi časem změny a časem aktualizace checksumu?Zkuste se zamyslet hlavou a přijdete na to. Hint: asi tak stejně, jako u toho Btrfs.
Proč vůbec explicitně a téměř manuálně dělat cosi navíc, co má dělat filesystém?Protože momentálně neexistuje filesystém, který by to uměl a kterému bych zároveň byl ochoten svěřit data, o která nechci přijít/obnovovat je ze záloh. Plus to, že by to "měl" dělat filesystém, je taky vaše zbožné přání, není důvod, aby to nemohla dělat jiná vrstva.
Protože tohle je na btrfs to nejzajímavější. Lidi tvrdí, jak jim scrub odhaluje jednu chybu za druhou. Dobrá, disky jsou nespolehlivé, vrací chybná data. Jak je možné, že jsem za ty roky nenarazil na něco, co by bylo rozbité? Špatně přečtený program bude dělat kraviny nebo padat, pokažený soubor nepůjde otevřít nebo bude obsahovat nesmysly... a ani na jedno z toho jsem ještě nenarazil. Při kopírování dat mezi disky dělám sha256sum na všechny přenesené soubory a vždycky všechno v pořádku. Před zálohováním dělám checksum souborů v záloze proti aktuálnímu stavu a vždycky všechno v pořádku.Jeden disk od Seagate mi tohle dělal. Pokud jsem ho zapnul, přečetl sektor, vypnul, zapnul a znovu přečetl, vrátil s trochou štěstí odlišná data. Asi záleží také na tom, co si kdo koupí a jak je to staré. Disky od WD často odchází tak, že (odhadnuto poslechem) hýbou hlavičkou tam a nazpátek a IIRC po 120 s to vzdají a hodí chybu, kterou jistý OS/FS od jisté firmy zcela ignoruje, ale po těch 120 s je zatuhlý celý OS nebo aplikace. Jednou jsem se někomu takhle někomu zaposlouchal do zvuků dusíku a oznámil jsem mu, že mu odchází disk. Disk SMART test za svojí životnost viděl jen jednou a když jsem ho sputil, nahlásil chyby.
Disky od WD... mi vzhledem k tomu, jaký mají firmware a jak jim "funguje" SMART, už nesmí do baráku. Jinak to, co popisujete, AFAIK dělají disky do desktopů - u těch se počítá s tím, že to nemáte v RAIDu a že jediná šance, jak ta data zachránit, je přečíst je. Pokud si koupíte disk do datacentra (což bude stejné zařízení s jiným firmwarem), tak se tolik snažit nebude - ohlásí chybu a ať si to dořeší RAID.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.