On Fri, Oct 07, 2005 at 01:09:21PM +1000, Neil Brown wrote: > However it is usually easier to read a whole patch - reading a patch > that removes bits of a previous patch, and depends on other bits of > it, requires holding too much in one's brain at once. If you could > possibly send a complete patch against a recent release kernel, it > would make review a lot easier. Mm, OK. >> I'm unsure how much this actually buys us (there's a slight reduction in >> complexity, but I fear that will go up again once I implement it for read >> stripes as well), > I think it buys us a lot. It means we can wait for stripes to become > free instead of spinning around hoping they will come free soon. Well, I've been doing printk-debugging on this, and it's actually a quite rare case (even with heavy I/O) that it's starved for stripes. > Currently the patch looks mostly good, but there are a couple of > structural changes that I think it needs as I mentioned previously. > Once these are in place, I can review the code more closely and look > for races and other subtle semantic issues. Mm. I'm still a bit ambivalent about a rewrite; I need something working in about exactly a month (when we're going to restripe our backup server) and a rewrite would no doubt destabilize it all for quite a while. My test server is currently broken after I tried to get in a kdb-enabled kernel; grub conveniently broke at about the same time :-) I'm not sure how much time I can dedicate to this ATM either. I definitely agree moving code into sync_request would result in a better overall model, though, with less overhead in the usual (non-restripe) paths. /* Steinar */ -- Homepage: http://www.sesse.net/ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
