tech-userlevel archive


Re: swap-on-raidframe vs raidctl -P

In article <200801221529.KAA29498%Sparkle.Rodents.Montreal.QC.CA@localhost>,
der Mouse  <mouse%Rodents.Montreal.QC.CA@localhost> wrote:
>I've just set up a 4.0 machine at work.  It's using raidframe for
>everything (well, not quite; there's a tiny boot partition that's not
>formally raided, though it is mirrored another way), and I saw a
>Swap is on raid0b, and, when raidframeparity ran, it complained that
>raid0 parity was dirty and started a parity rewrite.  This is hardly a
>catastrophe; the rewrite finishes fast enough that it's not a huge
>problem.  But it seems to me that this is suboptimal.
>I see two possible fixes.
>One would be a way to configure raidframe for uses (like swap) that
>don't care about data preservation when the partition is not in use;
>parity rewrite at boot would be dummied out for such partitions.  (Only
>at boot; if a member fails and is replaced, the resulting rewrite
>should not be dummied out, at least not for blocks that have been
>written since boot - and keeping track of which blocks that is would be
>expensive enough that I'd be inclined to say it shouldn't be done.)
>The other would be to run raidframeparity earlier, before swap is
>It seems to me that each should actually be done, independent of the
>other, but either one would be good enough for my purposes.  The former
>would be more intrusive as far as raidframe is concerned; I'm not sure
>the latter is possible, since I don't have my head around why it's run
>where it is now (rather than as part of raidframe).

I am working on a patch that unconfigures swap on shutdown. I am having
some trouble with it, because of the state of flux that vnode reference
counting is in, but I hope to commit it as soon as it works.


Home | Main Index | Thread Index | Old Index