Subject: Re: RAIDframe: why are only "root" raidsets closed on reboot/halt?
To: Greg Oster <oster@cs.usask.ca>
From: Eric S. Hvozda <hvozda@ack.org>
List: tech-kern
Date: 11/26/2002 00:34:02
On Sun, 24 Nov 2002 10:27:14 -0600 Greg Oster wrote:
>
> Hmmm... That shouldn't be the case. Any RAID set (whether auto-configured or
> not) that has all open partitions closed will have the parity status bits
> updated properly...
Interesting.
Perhaps I should supply more detail. I have built a stripe of
mirrors. I have tried striping the mirrors with both RAIDframe
and ccd (all mirrored components are RADIframe based of course).
Both methods yeild the same behavior: One or more of the mirrors
of stripe are "dirty" on restart.
> If the partitions on those sets get closed, then the corresponding RAID sets
> will get properly taken care of.. If something keeps a partition open, then
> the RAID set won't get properly shutdown.
Hmmm, if I am in single user mode and have done a "umount -a"
ensuring all file systems are silent before the reboot (the root
file system is its own raidset and always closes as you mention)
I still get dirty mirrors.
I note that if I "ccdconfig -U" for "raidctl -u" the stripe first,
parity will stay clean. However I will note that in any event I see
the root raidset closed (as per the console messages) as follows:
syncing disks... done
Closing vnode for row: 0 col: 0
Closing vnode for row: 0 col: 1
rebooting...
I never see any of the other sets give the "Closing vnode for row"
message. Perhaps the closing of the vnode for the components has
nothign to do with the fact that parity stays clean or not? I must
admit I have not delved too deeply into the source yet.
So it appears I may be wedging open the raidsets with the stripe
(as you theorized). However, I have got to believe there are others
out there attempting to build complex io systems with RAIDframe as
well, so I believe this is an issue worth looking at.
I suppose I could RAID 5 across the two controllers, but I really
don't want the speed hit.
It seems that there is a similar kind of thing with umounting all
filesystems at shutdown in that they have to be umount'd in a
specific order or parent fs's won't umount (ie /var/mail must umount
before /var).
I'll have to take a closer look at the source...