Ric Wheeler wrote:
David Masover wrote:
Why do you presume to make this decision for users?
It's not a decision that I want to make for users, it is a decision that
Hans and his team need to make about how best to spend their limited
resources.
Agreed. It's not important if it takes more than, say, an hour.
It will also give more users a bad experience with the file system,
since users rarely have the in depth knowledge required to make this
kind of choice.
While it's true that most users just click through dialog boxes, I
imagine this would be sufficient:
===WARNING===WARNING===WARNING===
---------------------------------
THIS DISK IS BAD!
If you continue with the format,
we will not help you when you lose data.
When, not if. You are strongly encouraged to
THROW THIS DISK OUT!
---------------------------------------------
ARE YOU ABSOLUTELY SURE YOU WANT TO CONTINUE?
(yes/no):
And require an actual "yes" or "no" answer. No "y/n".
Now, compare that to a filesystem which doesn't allow badblocks in mkfs
at all. While it's rare, I suspect that would be a worse experience if
you actually had a real need for it. If you've got a huge 300 gig drive
with some bad blocks, you can always throw some stuff on it anyway, for
backup, or stuff you don't care about, even knowing it'll fail soon.
Again, probably not a high priority item at all, but it certainly won't
make the user experience worse. Any user who says "yes" to the above
warning does not get to complain about their experience.
Here we mostly agree. The need for enhanced tools is not to encourage
people to keep using bad drives, rather to allow them to fsck & remount
a drive for data recovery. If you cannot mount & fsck fails to repair
enough to give you at least a readable file system, then you are in real
trouble ;-)
Also, unlike failing writes, disk read errors are quite often ephemeral
and will be self correcting on the next write (you might get an error
from dust, etc that gets "swept" clean on the next write).
Either one, I would personally feel quite a lot safer grabbing a disk
image and doing the fsck once the image was on known good media.
One thing that would be even better here, though, if you don't want to
spend the time for a huge backup: A way to tell badblocks to only scan
space which is actually being used, and then enough free space to make
sure relocations work. If you're mounting readonly, you shouldn't care
about marking every single bad sector in free space. I guess this would
require a lot more intelligence from fsck, though -- it would have to be
able to constantly check for bad blocks, as opposed to just running
badblocks once and grabbing a list to avoid.
