strange badblocks problem

marnixk lfs at
Sun Jan 18 02:29:01 PST 2004

Bill's LFS Login wrote:

> Using the correct blocksize (-b) or specifying the count of blocks when
> using 1K (-c) should have some beneficial effects. I'm not sure exactly
> what will be fixed because I don't know what badblocks does when it gets
> a "short block" at the end of the partition. If it handles short reads
> followed by EOF (if it were sequentially reading), all the log messages
> should disappear. If it is not reading sequentially, there could still
> be some if it does not properly handle the error returned by the OS when
> it tries to read sectors beyond the end of the partition.

Okay, I have done the following:

cdimage root # badblocks -sv /dev/hda8
Checking for bad blocks in read-only mode
>From block 0 to 3036253
Checking for bad blocks (read-only test): 303625236/  3036253
Pass completed, 1 bad blocks found.

cdimage root # badblocks -sv -c1 -b 512 /dev/hda8
Checking for bad blocks in read-only mode
>From block 0 to 6072507
Checking for bad blocks (read-only test): 607250412/  6072507
Pass completed, 3 bad blocks found.

cdimage root # badblocks -sv -c1 -b 4096 /dev/hda8
Checking for bad blocks in read-only mode
>From block 0 to 759063
Checking for bad blocks (read-only test): done                        
Pass completed, 0 bad blocks found.

As would be expected after your post, giving the correct parameters to
badblocks solved the problem. Cool!

However, doing something similar with dd did not:

cdimage root # dd if=/dev/hda8 of=/dev/null bs=4096
dd: reading `/dev/hda8': Input/output error
759063+0 records in
759063+0 records out

and i know of no parameters that i could pass to cat, so this remains the
same also:

cdimage root # cat < /dev/hda8 > /dev/null
cat: -: Input/output error

> Much of what we discussed still holds since the number of sectors is not
> evenly divisable by 8.

I am going to repartion my disk *now*, so that all partitions hold a number
of sectors that is evenly divisible by 8. Still, IMHO maybe partitioning
software should take care of this automatically, or the kernel/applications
should handle this better? I say this because not everybody carefully
determines its partitions in terms of the number of sectors in them being a
multiple of 8. However, i'm beginning to believe that it actually is not a
*big* problem, since normal programs just use the FS, instead of the raw
partition... And i have seen no actual problems with FS. The reboot needed
after fsck-ing the root partition i described earlier has only occured once
or twice, and may not be related to this problem...

> I'm not sure what is updating the FS information ATM. It would not
> surprise me if getting badblocks to see the correct blocksize and
> block count stopped this. Or not. Of course, having the partition end on
> a block boundary should also provide benefit.

see above. In a previous post i compared the normal superblock with a backup
superblock and they appeared the same (if i did it correctly). So i think
nothing is updating the FS information? Although this does not explain why
sometimes the problem seems to be affected by mount/unmount of course, but
maybe this is just some artefact of the partitions being not divisible by 8
as well. hmmm...

> HTH (at last?)
You have been most helpfull and i've learned a lot. I will post the results
of my re-partitioning strategy later...I feel this *should* work!



More information about the lfs-support mailing list