linux-kernel - Re: raid6 grow "hangs" on 2.6.27 with mounted FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Mar 2009 16:02:48 +1100
From:	Neil Brown <neilb@...e.de>
To:	roma1390 <roma1390@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: raid6 grow "hangs" on 2.6.27 with mounted FS

On Saturday March 21, roma1390@...il.com wrote:
> i have 2.6.27
> trying thease command
> 
> # create raid6 with 4 block devices
> mdadm --create /dev/md2 --level=6 --raid-devices=4 /dev/loop{1,2,3,4}
> # wait to sync
> sleep 3
> # create and mount FS
> mkfs.ext2 /dev/md2
> mount /dev/md2 -t ext2 /mnt
> 
> # add block device and grow, wait for resync
> mdadm --add /dev/md2  /dev/loop5
> mdadm --grow /dev/md2 --raid-devices=5
> sleep 3
> 
> # dmesg prints: VFS: busy inodes on changed media.
> # umount hangs ...
> umount /dev/md2
> # also: "mdadm --query /dev/md2" hangs in D state.

Thanks for the detailed report.

I can almost reproduce this.
However when I run it, the "mdadm --grow" prints 
    mdadm: Need to backup 384K of critical section..
(as expected) and then hangs.

If I interrupt it and proceed, then the umount hangs.

Is this the case for you?

The umount hangs because there is something important that mdadm needs
to do which it didn't do because it was interrupted.  During the
'critical section', mdadm causes all writes to the start of the device
to be blocked.  The umount tries to write the filesystem superblock
and hangs.
You can test if this is the problem by running the command

 cat /sys/block/md2/md/suspend_hi > /sys/block/md2/md/suspend_lo

That should allow the 'umount' to complete.

This will only happen on very small arrays that take less than a
couple of seconds for the reshape to complete.  I have a patch for
mdadm which makes it more robust in this situation.  It will be in
future releases.

Does this explain what is happening to you?

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/