At 2004-08-09T12:09:40+1200, Volker Kuhlmann wrote:
Volker,
I think you misunderstand the point of the badblocks tool. It is not a
generic tool for detecting all bad sectors on a drive. It doesn't
contain any drive-level intelligence. It's really only useful in
specific cases where you need a list of bad sectors on a device that the
device is refusing to remap so that you can add the list of bad blocks
to the filesystem's bad blocks list manually.
It can be somewhat useful for running generic disk stress tests (as you
mentioned), since it will write and then read/verify data across the
disk--this isn't easily achievable with the likes of dd.
The documentation provided with badblocks does not make this as clear as
it could, so it's understandable that you're confused. I might file a
bug about that...
> Around the bad sectors, the disk makes some clicky noises, and each
> time the kernel decides to give up and disable DMA. Result: "Your
> mouse has moved. Please wait for your mouse pointer to update". Typing
> any text at normal speed leads to random characters, one has to type
> the "hdparm -d1 /dev/hda" one character per second. (That much Sascha
> for running with DMA off...)
There's really two things going on here. DMA is being turned off, which
(as you know) will have a dramatic effect on the system's performance
during I/O.
Secondly, the disk/IDE bus/kernel are busy trying to recover from the
media errors, which causes the disk (and really the whole machine) to
perform slowly. Even if DMA wasn't being turned off, you'd find that
the machine performs poorly because I/Os to the disk will block for
multiple seconds, this will usually cause any process attemping even the
smallest I/O to block--thought at least in this case the performance
would only suck while the bad areas of the disks were being touched.
> I stick with my opinion that this kind of kernel design is
> unacceptable - all the hardware works just fine with DMA.
So report a bug to your Linux vendor, or get in touch with the kernel
IDE maintainer. There's no point ranting about it on _this_ list.
The Heaven's Gate followers stuck with their opinion too. Doesn't mean
they were right or in touch with reality. ;-)
> Afterwards, the disk had 4 more reallocated sectors. Badblocks'
> opinion? "Problem? What's that?" As a tool it's not any more useful
Not at all surprising. badblocks does not have any low-level knowledge
of the disk, so it's just doing normal I/O to the device file using
fairly plain open/read/write/close calls. If the disk decides to remap
sectors during a badblocks run, there's nothing badblocks can do to
detect this, and you're better off having the disk remaps the sectors
(and have the bad sectors hidden permanently) than adding the bad
sectors to the filesystem's bad blocks list and having to remember to
re-add those blocks to the list next time you format the partition.
> It was very useful in the days of 50MB disks without cache (see its
> default of 16 for -c).
Well, badblocks defaults to using 1024 byte blocks, so 16x1024 is 16kB
per transfer, which is efficient for reasonably large disks.
Now that we're in the age of 300GB disks, it's probably not large
enough--so the badblocks from e2fsprogs 1.35 now defaults to 64 blocks
after someone bothered to raise a bug with the developers (Debian bug
#232240). Using '8192' is probably way too large and a waste of memory
(but you probably have plenty of that)--refer to the Debian bug
reference above for benchmarks run by Ted T'so, the e2fsprogs
maintainer.
> These days disks either work or get replaced.
Yes, virtually anyone with a clue will tell you to replace the disk
rather than mucking around with it.
> (I'm not complaining, just saying that if people expect badblocks to
> tell them their bad blocks, they're running a high risk of being
> disappointed.)
It'll provide the user with a list of unremapped bad blocks that is
suitable for use as the filesystem's bad blocks list. It even says in
the man page for badblocks: "it is strongly recommended that users not
run badblocks directly, but rather use the -c option of the e2fsck and
mke2fs programs." (which doesn't help reiserfs users much).
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
