strange badblocks problem

Bill's LFS Login lfsbill at nospam.dot
Fri Jan 16 08:34:25 PST 2004


On Thu, 15 Jan 2004, marnixk wrote:

> Bill's LFS Login wrote:
><snip>

Sometimes a cluebat is required to make me begin traveling the right
path.

Went back and started re-examination from your first post (because I had
become somewhat lost after the post where you switched partitions). An
*insignificant* (yeah, right) datum from tune2fs suddenly connected in
my associative processor. You need to specify the blocksize when you run
the badblocks program (-b parameter) with a blocksize that is the same
as used when creating the file system.

In that first post, the only badblocks command you posted showed a 1K
blocksize. I think this is also the default badblocks uses if you don't
specify a blocksize (I couldn't find any ref to a default in 'man
badblocks', but your posts seem to indicate that it defaults to 1K).

Also from 'man badblocks':

  last-block is the last block to be checked; if it is not specified,
  the last block on the device is  used  as a default.

Note that bad blocks will check to the end of the *device*, *not* the
file system. You can see where this will lead, right? Badblocks will not
stop checking the last *block* in the FS, but will continue to the end
of the device, which includes sectors that are not part of the file
system. So, with the partition having a number of blocks that is not
evenly divisable by the blocking factor in use (whether 1K, 2K or 4K),
the last read of the *device* will do at least one and maybe two
undesirable things. It will check blocks that are not part of the file
system (and if you were saving output to a file that would be passed to
mke2fs or e2fsck that would then cause problems). It apparently treis to
also read the sectors beyond the partition end as it tries to check a
full block's worth of sectors, which it is expecting to find. This can
be suppressed by using the -c parameter.

Also from 'man badblocks':

  Important note: If the output of badblocks is going to be fed to the
  e2fsck  or  mke2fs  programs, it is important that the block size is
  properly specified, since the block numbers which are generated are
  very dependent  on  the block size in use.   For this reason, it is
  strongly recommended that users  not  run  badblocks  directly, but
  rather use the -c option of the e2fsck and mke2fs programs.

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.

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.

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

HTH (at last?)

-- 
NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
lfsbillATearthlinkDOTnet
Fix line above & use it to mail me direct.



More information about the lfs-support mailing list