Hi!
When my root filesystem is on an MD (RAID5) array, I can't cleanly shut
down (trying to change the array ro, even when nothing else than the
kernel threads and init and one bash are running, and the root fs is ro
remounted), because I've got "md: md0 still in use" kernel messages.
Usually it doesn't cause any problems, but it possibly could leave the
array in an inconsistent state (resync required after reboot).
I made a patch for md.c, based on the thread on "Can't get md array to
shut down cleanly" started at 2006-07-06 on linux-raid@vger.
The problem is reproducible on kernel v. 2.6.17.5 and 2.6.17.11, this
patch is made for the latter.
Please check this patch, for me it does work, but I'm not sure, that it
doesn't break something else. I'm not on the list, please CC me.
Here is the diff for drivers/md/md.c:
2789c2789
< if (atomic_read(&mddev->active)>2) {
---
> if (atomic_read(&mddev->active)>2 && !ro) {
--
Czigola, Gabor
On Friday October 6, [email protected] wrote:
> Hi!
>
> When my root filesystem is on an MD (RAID5) array, I can't cleanly shut
> down (trying to change the array ro, even when nothing else than the
> kernel threads and init and one bash are running, and the root fs is ro
> remounted), because I've got "md: md0 still in use" kernel messages.
> Usually it doesn't cause any problems, but it possibly could leave the
> array in an inconsistent state (resync required after reboot).
When your machine shuts down, all md arrays are automatically switched to
read-only *after* the root filesystem has been unmounted. You should
get a message
md: stopping all md devices.
if you get e.g.
md: md0 still in use.
*after* that message then there might be a problem. Otherwise
everything should be fine.
That being said, it is possible that your patch is OK. I've been
meaning to review the rules for switching an array to read-only for
ages, but it never got to the top of the todo list. e.g. do you want
to be able to switch an array to read-only when a filesystem is
mounted read-write off it. If you don't, how do you check? If you
do, what about in-flight write requests? Do you need to wait for them
to complete? How? It isn't as straight forward as one might like.
NeilBrown
Thank you for your answer!
On Mon, 9 Oct 2006, Neil Brown wrote:
> if you get e.g.
> md: md0 still in use.
> *after* that message then there might be a problem. Otherwise
> everything should be fine.
Yes, I've got exactly that, and rarely after such a reboot the array
started to resync.
> That being said, it is possible that your patch is OK. I've been
> meaning to review the rules for switching an array to read-only for
> ages, but it never got to the top of the todo list. e.g. do you want
> to be able to switch an array to read-only when a filesystem is
> mounted read-write off it. If you don't, how do you check? If you
> do, what about in-flight write requests? Do you need to wait for them
> to complete? How? It isn't as straight forward as one might like.
>
> NeilBrown
I realised afterwrds, that this patch makes it possible to stop an array
even it has a rw mounted filesystem on it. But I can easily remember not
to switch the array to ro before umounting (remouning ro) the
filesystem(s) on it, in return the array stops surely sync-d.
Of course, this isn't a solution for the kernel. But wouldn't it be
possible to get the required information from the mount tables of the
kernel? About pending write request to the md device does the subsystem
already know.
--
Czigola, Gabor