On Sun, 23 Oct 2005 22:43:26 +0200 Rogier Krieger <[EMAIL PROTECTED]> wrote:
> On 10/23/05, Ken Gunderson <[EMAIL PROTECTED]> wrote: > > Now my question is whether there is some way to shorten > > this delay that I'm missing? > > Did you read through the list archives? This matter is well-discussed. > Other OS'es, such as NetBSD, use a different way for the checking of > parity (i.e. in the background). For the record I am a pretty experienced *nix sysadmin and typically do my homework reasonably thoroughly before asking others for help. Admittedly I did not read every post and there are times when even the best of us miss the obvious. But let me assure you that I did look. I'm not familiar w/NetBSD. I also do not recall encountering any references to background parity checking in the man pages. Am I correct in assuming you're refernecing the rc "raidctl -P all &" hack?? Or did you have something else in mind? Since it's apparent to me that: 1) having such a long wait after a hard crash is suboptimal 2) OBSD is an excellent and mature *nix 3) and many others have gone before me 4) Despite being a legend in my own mind, I may well have missed something. So I am braving the legendary wrath of misc and inquiring. If you could provide a pointer I'd appreciate it. There's a lot of posts, not always labeled w/ the most appropriate subject. > The caveats with this approach are listed in the man pages for > raidctl(8) and raid(4). I have read the man pages. More than once. For example, I read this in raid (4) "Recomputation of parity MUST be performed whenever there is a chance that it may have been compromised. This includes after system crashes, or be- fore a RAID device has been used for the first time. Failure to keep..." And then again in raidctl (8): "Recomputation of parity MUST be performed whenever there is a chance that it may have been compromised. This includes after system crashes...." Now I take MUST written in all caps as really meaning MUST. So that makes me shy away from the /etc/rc hack. This is a root on raid configuration. So when the system boots the raidsets are configured automatically. Boot needs to complete before I have access to tools such as raidctl to turn off auto. Now it occurs to me that I could just pull one of the drives after a hard failure. Then the parity check would get short circuited, the missing drive failed as "component 1" and the raidset marked "dirty", and the system would come up much quicker. Then proceed w/ a raidctl - R followed by a raidctl - P. Which seems an awful hack on par with backgrounding the parity check in /etc/rc. Other than these two hacks, however, it eludes me. And since the theme of the 3.8 release is "Hackers of the Lost Raid", I am wondering if OBSD might have something slick up it's sleve that might not be too well documented as of yet. Suggestions and pointers welcome. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon?
