All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Masover <ninja@slaphack.com>
To: Hans Reiser <reiser@namesys.com>
Cc: Ric Wheeler <ric@emc.com>, Peter <sw98234@hotmail.com>,
	reiserfs-list@namesys.com
Subject: Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Date: Wed, 06 Sep 2006 10:08:11 -0500	[thread overview]
Message-ID: <44FEE45B.4060607@slaphack.com> (raw)
In-Reply-To: <44FE1C04.70800@namesys.com>

Hans Reiser wrote:
> Ric Wheeler wrote:

>> Having mkfs ignore bad writes would seem to encourage users to create
>> a new file system on a disk that is known to be bad & most likely not
>> going to function well.  If a user ever has a golden opportunity to
>> toss a drive in the trash, it is when they notice mkfs fails ;-)  This
>> option to mkfs sounds like an invitation to disaster.
> Yes, you are right, the option should be to run badblocks and then fail
> if it finds any.

Unless it creates significantly more work for us, there should be an 
option to run badblocks, and if it finds any, it should prompt the user 
(with BIG FAT CAPSLOCK WARNINGS) whether they want to format anyway. 
Formatting anyway should work, and we should be able to have blocks 
marked bad.

It would also be nice to be able to change this later -- to pass in a 
list of badblocks to, say, fsck (which I think is the original request). 
  This is especially nice for recovery, if you don't have the luxury of 
copying a whole disk image to another drive before running fsck.

That's not to say that we should automatically detect and relocate bad 
blocks during normal operation (while the FS is mounted), but 
deliberately removing functionality to protect you from yourself isn't 
the Linux Way.  Linux has a long history of kernel config options that 
say things like "YOU WILL LOSE DATA. You have been warned."

  reply	other threads:[~2006-09-06 15:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-01 18:23 FEATURE Req: integrate badblocks check into fsck.reiser* Peter
2006-09-01 18:50 ` Vladimir V. Saveliev
2006-09-01 19:26   ` Hans Reiser
2006-09-01 22:27   ` David Masover
2006-09-01 23:00     ` Hans Reiser
2006-09-01 23:02     ` Peter
2006-09-01 23:12       ` David Masover
2006-09-01 23:16         ` Hans Reiser
2006-09-04  2:41         ` Ric Wheeler
2006-09-06  0:53           ` Hans Reiser
2006-09-06 15:08             ` David Masover [this message]
2006-09-07 10:35               ` Ric Wheeler
2006-09-07 16:22                 ` David Masover
2006-09-07 17:10                   ` Ric Wheeler
2006-09-07 17:35                     ` David Masover
2006-09-08 12:29                       ` Peter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44FEE45B.4060607@slaphack.com \
    --to=ninja@slaphack.com \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=ric@emc.com \
    --cc=sw98234@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.