HTFS fsck spins on CPU
From Wikistix
It appears SCO HTFS appears to have a bug where fsck may spin on the CPU while processing the filesystem transaction log. This was seen on SCO OpenServer(TM) Release 5, 3.2v5.0.5.
Both the following fsck commands hung, and were killed:
# fsck -d -n /dev/rfs01 /dev/rfs01 (NO WRITE) HTFS File System: Volume: attempting a fast fsck... log ino 3, txid 8848 block 0 = 560086 block 1 = 560087 block 2 = 560088 block 3 = 560089 block 4 = 560090 block 5 = 560091 block 6 = 560092 block 7 = 560093 block 8 = 560094 block 9 = 560095 log size = 180 NO PARTIAL TRANSACTIONS PENDING sync log ino 5 sync log size 32768 saving stale offset 0 skipping offset 0 slog header: cksum 00001963 tstamp 0cd83b95 pstamp 00000000 size 7280 slog entry: ino 3956 off 9168 len 7216 origlen 7216 reclen 7280 time 46311afa writing sync log entry ino 3956 off 9168 len 7216
# fsck -d -n -o full /dev/rfs01 /dev/rfs01 (NO WRITE) HTFS File System: Volume: ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Synchronous Write Log sync log ino 5 sync log size 32768 saving stale offset 0 skipping offset 0 slog header: cksum 00001963 tstamp 0cd83b95 pstamp 00000000 size 7280 slog entry: ino 3956 off 9168 len 7216 origlen 7216 reclen 7280 time 46311afa writing sync log entry ino 3956 off 9168 len 7216
The fix was to use fsdb to fool SCO into believing the filesystem transaction log (.slog0000) was corrupt, and allow fsck to recreate it:
First, double check that inode 5 is the filesystem transaction log:
# fsdb /dev/rfs01 /dev/rfs01(): HTFS File System FSIZE = 17922240, ISIZE = 4480560 2i.a0b.p128d d 0: 2 v0 12 1 . d 12: 2 v0 12 2 .. d 24: 3 v0 20 9 .ilog0000 d 44: 4 v0 20 10 lost+found d 64: 5 v0 20 9 .slog0000 d 84: 6 v0 16 5 users d 100: 3897 v0 16 7 support d 116: 3905 v0 16 5 mydb
Now display inode 5 and change its size to zero:
5i i#: 5 md: f------------ ln: 1 uid: 0 gid:60007 sz: 32768 a0:560097 a1:560098 a2:560099 a3:560100 a4:560101 a5:560102 a6:560103 a7:560104 a8:560105 a9:560106 a10:560107 a11: 0 a12: 0 at: Fri Feb 16 15:57:45 2007 mt: Fri Feb 16 15:57:45 2007 ct: Fri Feb 16 15:57:45 2007 i5.sz=0 q #
At this point, you will need to re-run a full fsck, preferably twice, to correct any outstanding issues and fix the filesystem transaction log.
