From: Bill Cizek <cizek@rcn.com>
To: linux-raid@vger.kernel.org, Neil Brown <neilb@suse.de>
Subject: raid5 reshape bug with XFS
Date: Sat, 04 Nov 2006 19:59:57 -0600 [thread overview]
Message-ID: <454D459D.4000003@rcn.com> (raw)
Hi,
I'm setting up a raid 5 system and I ran across a bug when reshaping an
array with a mounted XFS filesystem on it. This is under linux 2.6.18.2
and mdadm 2.5.5
I have a test array with 3 10 GB disks and a fourth 10 GB spare disk,
and a mounted xfs filesystem on it:
root@localhost $ mdadm --detail /dev/md4
/dev/md4:
Version : 00.90.03
Creation Time : Sat Nov 4 18:58:59 2006
Raid Level : raid5
Array Size : 20964480 (19.99 GiB 21.47 GB)
Device Size : 10482240 (10.00 GiB 10.73 GB)
Raid Devices : 3
Total Devices : 4
Preferred Minor : 4
Persistence : Superblock is persistent
[snip]
------------------------------------
...I Grow it:
root@localhost $ mdadm -G /dev/md4 -n4
mdadm: Need to backup 384K of critical section..
mdadm: ... critical section passed.
root@localhost $ mdadm --detail /dev/md4
/dev/md4:
Version : 00.91.03
Creation Time : Sat Nov 4 18:58:59 2006
Raid Level : raid5
Array Size : 20964480 (19.99 GiB 21.47 GB)
Device Size : 10482240 (10.00 GiB 10.73 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 4
Persistence : Superblock is persistent
-----------------------------------
It goes along and reshapes fine (from /proc/mdstat):
md4 : active raid5 dm-67[3] dm-66[2] dm-65[1] dm-64[0]
20964480 blocks super 0.91 level 5, 64k chunk, algorithm 2 [4/4]
[UUUU]
[====>................] reshape = 22.0% (2314624/10482240)
finish=16.7min
speed=8128K/sec
------------------------------------
When the reshape completes, the full array size gets corrupted:
/proc/mdstat:
md4 : active raid5 dm-67[3] dm-66[2] dm-65[1] dm-64[0]
31446720 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
- looks good, but-
root@localhost $ mdadm --detail /dev/md4
/dev/md4:
Version : 00.90.03
Creation Time : Sat Nov 4 18:58:59 2006
Raid Level : raid5
>>
>> Array Size : 2086592 (2038.03 MiB 2136.67 MB)
>>
Device Size : 10482240 (10.00 GiB 10.73 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 4
Persistence : Superblock is persistent
(2086592 != 31446720 -- Bad, much too small)
---------------------------------
xfs_growfs /dev/md4 barfs horribly - something about reading past the
end of the device.
If I unmount the XFS filesystem, things work ok:
root@localhost $ umount /dev/md4
root@localhost $ mdadm --detail /dev/md4
/dev/md4:
Version : 00.90.03
Creation Time : Sat Nov 4 18:58:59 2006
Raid Level : raid5
Array Size : 31446720 (29.99 GiB 32.20 GB)
Device Size : 10482240 (10.00 GiB 10.73 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 4
Persistence : Superblock is persistent
(31446720 == 31446720 -- Good)
If I remount the fs, I can use xfs_growfs with no ill effects.
It's a pretty easy work-around to not have the fs mounted during the
resize, but it doesn't seem right for the array size to get borked like
this. If there's anything I can provide to debug this let me know.
Thanks,
Bill
next reply other threads:[~2006-11-05 1:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-05 1:59 Bill Cizek [this message]
2006-11-05 22:56 ` raid5 reshape bug with XFS Neil Brown
2006-11-06 5:48 ` Bill Cizek
2006-11-07 4:55 ` Neil Brown
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=454D459D.4000003@rcn.com \
--to=cizek@rcn.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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.