Bug 133965 - `fsck -y` automatically answers "y" to the question "duplicate/clone bad blocks"
`fsck -y` automatically answers "y" to the question "duplicate/clone bad blocks"
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Depends On:
  Show dependency treegraph
Reported: 2004-09-28 14:18 EDT by John Poelstra
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-05 04:49:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Poelstra 2004-09-28 14:18:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

Description of problem:
`fsck -y` automatically answers "y" to the question "duplicate/clone
bad blocks".

1) The man page says nothing about "y" applying to this situation. It
only says that "y" answers yes to all questions about whether or not
to fix a problem. If the disk is really hosed have "y" apply to this
option takes a lot of additional time.

2) The man page also says nothing about what the question/option of
cloning bad blocks (e.g. why would a user want to? how could they do
with these bad blocks, etc?)

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1. Load rawhide-9-27-04 and disonnect power abruptly
2. Manually run `fsck -y`

Additional info:

Created in while encountering bugzilla #133959
Comment 1 Thomas Woerner 2004-09-29 05:57:37 EDT
Excerpt from the manpage of fsck:

  -y  For  some filesystem-specific checkers, the -y option will cause
      the fs-specific fsck to  always  attempt  to  fix  any  detected
      filesystem corruption automatically.

This includes ALL filesystem corruptions and also bad blocks.

Closing as "NOT A BUG".
Comment 2 John Poelstra 2004-10-04 14:20:29 EDT
If I have selected the wrong component, please let me know.

I read the man page before posting the bug. The man page needs to be

1) The man page does not discuss "duplicating or cloning" bad blocks.

2) What is the benefit of "duplicating or cloning" a bad block...? How
can a user access the bad blocks and what would they do with them?

3) Why would "duplicating or cloning a bad block" be considered
"fixing" a problem on the disk? It appears that *copies* of the bad
blocks are being made as opposed to *fixing* them. 
Comment 3 Thomas Woerner 2004-10-05 04:46:08 EDT
1) A bad block is a hardware problem or failure and is not readable in 
   parts or complete. This is a problem for the filesystem, which might 
   have data in this block. 
2) The solution for this is to mark this block as bad and to copy all 
   available data to another block to reduce data loss.
3) The copy of the bad block might have usable data in it and the 
   filesystem is not using the bad block anymore so this is some kind of 
   fixing the filesystem.

Note You need to log in before you can comment on or make changes to this bug.