> ... badblocks tool. It is not a > generic tool for detecting all bad sectors on a drive.
However that is what it (wrongly) implies to be. > 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 > Using '8192' is probably way too large and a waste of memory Considering drives have a minimum of 2MB, often 8MB, cache I'd certainly try and stay above that (the man page explicitly says so) to be on the safe side. With -c <4MB> it uses 13MB of memory - a close to laughable amount. > Yes, virtually anyone with a clue will tell you to replace the disk > rather than mucking around with it. Sure. But it's useful to see how the various tools behave in this kind of situation. > 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." So what... If I only want to check parts of a partition (which may not even have a filesystem!), anyfsck -c is no good and I have to get into numbers. Reiser rightfully doesn't put badblock handling on a high priority because usable hard disks don't have user-visible bad blocks (ok, small amount of generalisation). Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
