At 2004-07-30T16:51:16+1200, Volker Kuhlmann wrote:
> Unlikely, at a total of 6 remapped blocks?
Where do you get the figure '6' from? The remapping process is supposed
to be completely invisible outside of the drive. Any value SMART is
reporting is probably an additional counting scheme, separate from what
the internal remapping scheme is already using.
> No, the errors started occuring before I upgraded. The current
> smartmontools is better: it sends me email about it.
So it could be a bug that has existed for a while and the errors have
begun recently as a result of an interaction between the bug and some
other change... it's unlikely, but not impossible.
Run badblocks in read-only on the disk to see if it turns anything up.
Run a read-only fsck across the suspect partition too.
> I don't see how - the only argument taking a block number is -1, and
> that's "print the block". Combined with -p and/or -S it spits
> something, but it's not a filename. I was hoping for something like
> find-me-the-filename --lba 0x0067fdcc /dev/hda (and there are several
> partitions on it)
It's not that simple. You need a filesystem specific tool to work out
that kind of information--the rest of the system has no need to know
where the file is on disk.
As an example, think of the tail packing feature in reiserfs. Given an
arbitrary block on disk, the only part of the system that can possibly
know what file(s) are contained in that block is the filesystem code.
And even in this case, the filesystem has no need for a procedure that
maps a block on disk back to a file, since the filesystem works in
reverse--it already knows that blocks it has allocated, and where.
Or, for another example, think of hard links.
This is usually where the FS-specific fsck or debugger tools come in.
First you need to work out which partition is affected. Convert the
hexadecimal LBA address you get from smartmontools to decimal, then
compare that with the output of 'fdisk -lu /dev/hdX'.
Work out which filesystem block is affected--disk blocks are 512 bytes,
filesystem blocks are often 4096 bytes, but can vary. Example: the
error is detected on disk block 8000, and your filesystem uses 4kB
blocks, so the FS block will be 1000.
At this point, if you were using ext[23], it'd be a fairly simple matter
of firing up debugfs and using the icheck and ncheck commands to find
the affected file. Unfortunately, debugreiserfs isn't anywhere near as
full featured and it is a significantly more labour-intensive process.
Since you're after a 'find-me-the-filename' utility, I won't go into
the glorious detail of debugreiserfs unless you ask. ;-)
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
