Eida.cz - Když stroj času přece spadne ze stolu

Když stroj času přece spadne ze stolu

13. května 2013, 14:01 Eida

Už po čtvr­té. A při­tom stokrát ji­nak. Na kon­ci úno­ra jsem si tu ve­se­le po­chvaloval prav­dě­po­dobně sta­bilní stroj ča­su díky změně vnitřní da­ta­báze na paměť­ově do­časnou a od­děl­eným ča­sovým kapsám. Přes­to jsem tuhle v ne­dě­li ráno na­ho­dil Mac a mís­to čerstvých novi­nek na Twit­te­ru mě přivít­a­la ta ošk­l­ivá hláška o chy­bě běh­em kon­t­ro­ly zál­oh ve stro­ji ča­su.

Ukázalo se, že nasta­vení zál­o­hování je si­ce sta­bilní, ale síť sa­ma o so­bě není stavě­na na přežívání vyšš­ího vy­pa­dávání kabe­lů a růz­ných bludných impulzů a po­dobně a kapsa se poško­di­la stejným způ­s­o­bem, ja­ko když se běh­em zápi­su z USB na­tvr­do vy­trh­ne fla­shka. Což je si­ce fajn vě­dět, ale nic to ne­měni­lo na tom, že by­la ča­sová kapsa poško­zená a vi­di­na ztrá­ty zál­oh od sa­motného za­čátku roku ne­by­la pros­tě a jedno­du­še při­ja­telná.

Za­jí­mavé je, jak se po In­terne­tu po­valuje spous­tu návo­dů, jak ča­sovou kap­su ošet­řit a něk­te­ří ta­koví se dokon­ce nesty­dí pod svůj návod na­paš­tit Do­na­te tla­čít­ko z PayPalu, přes­tože píší o kravi­nách a niko­mu je­jich text ne­po­může. Je to pro­to, že to­mu pros­tě ne­ro­zumí a jen opi­su­jí po­stu­py získ­ané kde­si jin­de a pokaž­dé k nim ješ­tě při­da­jí kou­sek mý­tu, mys­te­rie a tajem­na, aby uděl­a­li chu­dáky z ne­bo­hých čtenářů s poško­zený­mi kapsa­mi.

Co si te­dy správně po­čít? Zákla­dem je vniknout do nasta­vení stro­je ča­su a vypnout au­to­ma­tické zál­o­hy. Pak bych z růz­ných ji­ných dův­o­dů do­po­ru­čil restar­tovat ne­ta­talk, co kdy­by náh­o­dou něk­de zůstalo vi­set něj­a­ké po­chybné spo­jení. Po restar­tu sta­čí připo­jit sha­re ob­sahu­jí­cí kap­su a můž­e­me za­čít chr­lit.

Či­li ja­ko první ze se­be pro po­hod­lí uděl­á­me ro­o­ta a připraví­me si kap­su. Je vel­mi prav­dě­po­dobné, že se kapsa zamknu­la a je potře­ba ji odemknout. Je vel­mi ne­do­po­ru­čeno to děl­at v GUI ve Fin­de­ru, pro­tože Fin­der začně za­pi­sovat svo­je me­ta­da­ta pří­mo do kapsy a může se tím pá­d­em stát, že se kapsa z da­ta­bázových dův­o­dů tře­ba zřítí znovu.

attach.txt 308 bajtů
$ sudo su
sh-3.2# cd /Volumes
sh-3.2# chflags -R nouchg <share>/<kapsa>.sparsebundle
sh-3.2# hdiutil attach -nomount -noverify -noautofsck <share>/<kapsa>.sparsebundle
/dev/diskX          	GUID_partition_scheme          	
/dev/diskXs1        	EFI                            	
/dev/diskXs2        	Apple_HFS 
Od­blo­kování a připo­jení kapsy

A ta­dy to za­číná být za­jí­mavé, pro­tože do­j­de k jevu, o kte­rém se ve výše zmíněných pseu­dově­deckých člán­cích běžně ne­dá do­číst. Uti­litka hdiu­til si­ce do­sta­la pa­ra­me­t­ry nove­rify a no­au­tofsck, ale ja­ko z čis­tého ne­be přes­to začne kap­sičku na po­za­dí kon­t­ro­lovat. Takže když běžný smr­telník zku­sí pou­žít další za­ru­čený po­stup pro kon­t­ro­lu, vy­padne na něj hláš­ení, že je zam­čený žurnál a kapsa je jen pro čtení. Če­muž stejně asi ne­ro­zumí a jde bre­čet na diskusní fó­ra.

no_write.txt 160 bajtů
sh-3.2# fsck_hfs -drfy /dev/diskXs2
Unable to open block device /dev/diskXs2: Resource busyjournal_replay(/dev/diskXs2) returned 16
** /dev/rdiskXs2 (NO WRITE)
Za­blo­kovaný žurnál

Není nic snazšího, než tu­to kon­t­ro­lu pros­tě a jedno­du­še sestře­lit, stejně by neu­děl­a­la žád­ný uži­tek a prav­dě­po­dobně by moh­la na­pá­chat i další ško­dy.

kill.txt 25 bajtů
sh-3.2# killall fsck_hfs
Ko­nec au­to­ma­tické kon­t­ro­ly

Pak te­dy můž­e­me onen po­stup vyzkou­šet znovu. Za násle­dek má mít pře­bu­dování B-tree ka­talogu (-r = -Rc) a opravu všech chyb, na kte­ré na­razí (-y). Há­ček je v tom, že by bylo potře­ba při­dat ješ­tě kon­t­ro­lu pře­t­o­ků (-Re) a možná i ztra­cených atri­bu­tů (-Ra), ji­nak větši­na poku­sů stejně skon­čí s brutální chy­bou:

fsck.txt 5.71 KiB
sh-3.2# fsck_hfs -drfy /dev/diskXs2
journal_replay(/dev/diskXs2) returned 0
** /dev/rdiskXs2
	Using cacheBlockSize=32K cacheTotalBlock=32768 cacheSize=1048576K.
   Executing fsck_hfs (version diskdev_cmds-557~393).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
Extent records for rebuilt file 4:
	[ 24196, 4096 ]
	[ 458116, 293888 ]
	[ 26998827, 5096 ]
	[ 27030077, 6144 ]
	[ 1159799, 19848 ]
	[ 27135864, 128400 ]
	[ 0, 0 ]
	[ 0, 0 ]
hfs_UNswap_BTNode: invalid node height (1)
btree file 4:  1000 records
btree file 4:  2000 records
btree file 4:  3000 records
btree file 4:  4000 records
btree file 4:  5000 records
btree file 4:  6000 records
btree file 4:  7000 records
btree file 4:  8000 records
btree file 4:  9000 records
btree file 4:  10000 records
btree file 4:  11000 records
btree file 4:  12000 records
btree file 4:  13000 records
btree file 4:  14000 records
btree file 4:  15000 records
btree file 4:  16000 records
btree file 4:  17000 records
btree file 4:  18000 records
btree file 4:  19000 records
btree file 4:  20000 records
btree file 4:  21000 records
btree file 4:  22000 records
btree file 4:  23000 records
btree file 4:  24000 records
btree file 4:  25000 records
btree file 4:  26000 records
btree file 4:  27000 records
btree file 4:  28000 records
btree file 4:  29000 records
btree file 4:  30000 records
btree file 4:  31000 records
btree file 4:  32000 records
btree file 4:  33000 records
btree file 4:  34000 records
btree file 4:  35000 records
btree file 4:  36000 records
btree file 4:  37000 records
btree file 4:  38000 records
btree file 4:  39000 records
btree file 4:  40000 records
btree file 4:  41000 records
btree file 4:  42000 records
btree file 4:  43000 records
btree file 4:  44000 records
btree file 4:  45000 records
btree file 4:  46000 records
btree file 4:  47000 records
btree file 4:  48000 records
btree file 4:  49000 records
btree file 4:  50000 records
btree file 4:  51000 records
btree file 4:  52000 records
btree file 4:  53000 records
btree file 4:  54000 records
btree file 4:  55000 records
btree file 4:  56000 records
btree file 4:  57000 records
btree file 4:  58000 records
btree file 4:  59000 records
btree file 4:  60000 records
btree file 4:  61000 records
btree file 4:  62000 records
btree file 4:  63000 records
btree file 4:  64000 records
btree file 4:  65000 records
btree file 4:  66000 records
btree file 4:  67000 records
btree file 4:  68000 records
btree file 4:  69000 records
btree file 4:  70000 records
btree file 4:  71000 records
btree file 4:  72000 records
btree file 4:  73000 records
btree file 4:  74000 records
btree file 4:  75000 records
btree file 4:  76000 records
btree file 4:  77000 records
btree file 4:  78000 records
btree file 4:  79000 records
btree file 4:  80000 records
btree file 4:  81000 records
btree file 4:  82000 records
btree file 4:  83000 records
btree file 4:  84000 records
btree file 4:  85000 records
btree file 4:  86000 records
btree file 4:  87000 records
btree file 4:  88000 records
btree file 4:  89000 records
btree file 4:  90000 records
btree file 4:  91000 records
btree file 4:  92000 records
btree file 4:  93000 records
btree file 4:  94000 records
btree file 4:  95000 records
btree file 4:  96000 records
btree file 4:  97000 records
btree file 4:  98000 records
btree file 4:  99000 records
btree file 4:  100000 records
btree file 4:  101000 records
btree file 4:  102000 records
btree file 4:  103000 records
btree file 4:  104000 records
btree file 4:  105000 records
btree file 4:  106000 records
btree file 4:  107000 records
btree file 4:  108000 records
btree file 4:  109000 records
btree file 4:  110000 records
btree file 4:  111000 records
btree file 4:  112000 records
RebuildBTree - InsertBTreeRecord failed with err 5 0x05 
RebuildBTree - numRecords = 112569
RebuildBTree - record 15 in node 2454 is not recoverable. 

 xxxxxxxx BTreeKey (length 58) xxxxxxxx 
38 00 18 DD 00 00 19 00 64 00 61 00 74 00 61 00   8.......d.a.t.a.
6D 00 61 00 6E 00 61 00 67 00 65 00 6D 00 65 00   m.a.n.a.g.e.m.e.
6E 00 74 00 2E 00 70 00 72 00 6F 00 70 00 65 00   n.t...p.r.o.p.e.
72 00 74 00 69 00 65 00 73 00                     r.t.i.e.s.

 xxxxxxxx BTreeData (length 248) xxxxxxxx 
02 00 8E 00 00 00 00 00 19 DD 00 00 D9 C7 88 CB   ................
29 51 37 CC BB 48 13 CD BB 48 13 CD 00 00 00 00   )Q7..H...H......
00 00 00 00 50 00 00 00 00 00 A4 81 01 00 00 00   ....P...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 50 ED 98 3B 00 00 00 00 00 00 00 00   ....P..;........
00 00 00 00 00 00 00 00 8B 00 00 00 00 00 00 00   ................
00 00 00 00 01 00 00 00 C9 9B 2B 00 01 00 00 00   ..........+.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00   
** The volume Time Machine Backups could not be repaired.
	volume type is pure HFS+ 
	primary MDB is at block 0 0x00 
	alternate MDB is at block 0 0x00 
	primary VHB is at block 2 0x02 
	alternate VHB is at block 1535795198 0x5b8a5ffe 
	sector size = 512 0x200 
	VolumeObject flags = 0x07 
	total sectors for volume = 1535795200 0x5b8a6000 
	total sectors for embedded volume = 0 0x00 
CheckHFS returned 8, fsmodified = 1
Typická kon­t­ro­la se selháním

Je to si­ce osvěd­čená magie, ale ne­chápu, proč se všu­de říká, že by se ne­mě­la pouš­tět grafická Disk Uti­li­ty, kte­rá to­hle umí na jedno kliknutí uděl­at sa­ma a pře­devším to udě­lá ví­ceprůc­ho­dově, což by v CLI si­ce vy­pa­dalo kru­topřísně a hacker­sky, ale vzhle­dem k to­mu, že tenhle pro­ces klidně za­be­re ho­di­ny (a ukous­ne si ce­lé gigabaj­ty pamě­ti), je lepší to ne­chat přec­hrou­pat au­to­ma­ticky. Je­di­nou pod­mínkou je ovšem ne­mít kap­su při­moun­tovanou.

Ať už se v kap­se stalo coko­liv, Disk Uti­liy prav­dě­po­dobně chy­by naš­la a na­pravi­la, takže kap­su můž­e­me odpo­jit, zavřít spo­jení se serve­rem a pro další stu­peň jis­to­ty úplně zastavit ne­ta­talk a jít uděl­at po­slední zbýva­jí­cí změ­ny, kte­ré se tý­ka­jí vnitřního uspo­řá­d­ání stavu kapsy v ko­řenu je­jího .spar­se­bun­dle.

plist.txt 208 bajtů
# com.apple.TimeMachine.MachineID.plist

# smazat
<key>RecoveryBackupDeclinedDate</key>
<date>2013-01-02T03:04:05Z</date>

<key>VerificationState</key>
# a VerificationState upravit na 1
<integer>1</integer>
Mo­difika­ce vnitřního stavu kapsy

Otázk­ou je, co uděl­at s přesko­čením ve­rifika­ce, ale ono je pros­tě možná lepší ne­chat to zkon­t­ro­lovat ví­ce­krát, než aby se něk­de sta­la další fa­tální chy­ba. Po opě­tovném na­ho­zení serve­ru a zapnutí au­to­ma­tických zál­oh lze případnou dlouho­trva­jí­cí ve­rifika­ci beztak zru­šit.

Pokud z to­ho­to plyne něj­a­ké pou­čení, pak je to zjiš­tění, že se­be­lépe nastave­vené kapsy, i kdy­by plavaly na ZFS, ne­mo­hou odo­lat úplně všem síťovým chy­bám a ma­sivní­mu ru­šení. A ta­ky to, že li­di stejně neč­tou a pokud to­mu ne­ro­zumí, tak asi dob­ře jim tak.

Eida
Tento článek přečetlo již 237 čtenářů (0 dnes).

Komentáře

Nový komentář