Bug 171862 - can't create degraded raid 4
can't create degraded raid 4
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
:
: 171855 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-27 02:17 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 2.6.2-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-20 15:35:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-10-27 02:17:57 EDT
+++ This bug was initially created as a clone of Bug #171855, to use my personal
reported id in bugzilla +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b5) Gecko/20051008
Fedora/1.5-0.5.0.beta2 Firefox/1.4.1

Description of problem:
Attempting to create a degraded raid 4 array produces the following output:

# mdadm -C /dev/md31 -l 4 -n 3 /dev/loop0 /dev/loop1 missing
mdadm: RUN_ARRAY failed: Input/output error

(It's not about the use of loop devices; I've actually run into this with actual
hard disk partitions.)

Sure enough, the last syscall that mdadm issues to the kernel fails with -EIO,
but I can't tell whether that's because the kernel is in error, or if mdadm is
passing incorrect parameters to the kernel.  Doing the very same operation with
-l 5 works, FWIW.

On the Fedora development tree, the raid components have already got their raid
superblocks written out (or so it seems to me), so a subsequent assemble brings
up the degraded raid successfully.  However, on a fully-updated FC4 box, I have
no such luck: the superblocks there don't match each other, so nothing happens.

Version-Release number of selected component (if applicable):
mdadm-1.11.0-4.fc4 kernel-2.6.13-1.1622_FC5

How reproducible:
Always

Steps to Reproduce:
1.mdadm -C -l 4 -n 3 /dev/loop{0,1} missing

Actual Results:  -EIO in the last ioctl, the one that, replacing -l4 with -l5,
immediately precedes the write() stating that the array was brought up successfully.

Expected Results:  It would be nice if this worked.

Additional info:
Comment 1 Alexandre Oliva 2005-10-27 02:18:37 EDT
*** Bug 171855 has been marked as a duplicate of this bug. ***
Comment 2 Doug Ledford 2007-07-03 11:55:42 EDT
The behavior you speak of with raid5 is because mdadm does a little performance
enhancement.  It automatically creates raid5 arrays as being degraded and adds
the final disk as a spare because reconstruction is faster than parity
generation.  In order to do this, it tells the kernel to assume the newly
created array is clean, but degraded, then adds the spare disk.  If it didn't do
this, then raid5 would give the same I/O error because when you start the array
as a degraded/dirty array, there is not enough disks to do reconstruction and
you get the I/O error.  If you pass the flag assume-clean on a raid4 create
command, it mimics the raid5 behavior of telling the kernel that it is a
degraded/clean array and successfully starts the array.

So, the assume-clean flag is a workaround for existing setups, and for the sake
of consistency, I went ahead and modified mdadm to treat raid4 like raid5 (since
they actually are the same, just a different parity layout) and it now
automatically creates raid4 arrays as degraded and rebuilds them.  If you have a
missing disk, you no longer need to pass in the assume-clean flag to get it to
assemble.  This will show up in mdadm-2.6.2-2 or later.
Comment 3 Fedora Update System 2007-07-05 15:12:04 EDT
mdadm-2.6.2-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 4 Fedora Update System 2007-07-09 11:47:45 EDT
mdadm-2.6.2-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2007-07-10 02:42:03 EDT
mdadm-2.6.2-4.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2007-07-20 15:35:03 EDT
mdadm-2.6.2-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

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