Hello again Jakob :) > -----Original Message----- > From: linux-raid-owner@vger.kernel.org [mailto:linux-raid- > owner@vger.kernel.org] On Behalf Of Jakob &PSgr;stergaard > Sent: Thursday, February 07, 2002 6:19 AM > To: Cajoline > Cc: linux-raid@vger.kernel.org > Subject: Re: raidreconf > > Thanks, that clears up everything. I tried moving some devices around, > > to different slots, and so far it only worked some times, while other > > times it failed, the raid driver couldn't find the partition that was on > > the moved disk. Moving the drives onto the same channel (from one drive > > per channel per controller) worked, as well as switching them around > > between channels and master/slave on the same channel. However, > > strangely enough, moving the drive from the onboard ide controller to > > one of the Promise controllers failed. The kernel would find the drive > > and the partition on it, but the raid driver wouldn't. I thought this > > had to do with the sequence of the drives or something close to that, > > but now I understand it is probably a problem related to the controllers > > and the chipsets. > > Do you have the promise controller driver compiled into the kernel, or > is it a loadable module ? > > It sounds like a bug, nonetheless. Actually, in that case the controller was a HighPoint HPT366 and it was built into a custom built 2.4.9 kernel, not as module. I really have no idea why it wouldn't work, the raid driver would just say it can't find the partition on that drive that was moved from the onboard ide to the hpt controller. > It will print out a message saying how much physical memory it detected > in the machine ("Detected XXX KB of physical..."), and a message saying > how many outstanding requests it will buffer ("A maximum of XXX > outstanding > requsts is allowed"). > > raidreconf should use approx. 1/3 of the physical memory in the machine, > so 7% seems a little low... > > > So, if it took 3 hours to add 50 gb to a 60 gb array, a rough > > calculation says it will take about 19 hours to add 100 gb to a 380 gb > > array, which is close to your calculations, yet still lower. > > My calculations was a very rough estimate - perhaps you will see a > performance degradation when moving to larger partitions (because average > seek time will be slightly higher), but I'm not sure if that is going > to be noticable at all. ... > > On another note, I also noticed I currently use a 32 kb chunk-size, > > which is rather small for such a large array, while it also doesn't seem > > very useful since we don't have such a large number of small files. So I > > thought I should perhaps it would be wise to also convert to a 64 kb > > chunk-size. > > The question is a. is it safe to do such a conversion at the same time > > as adding the new device to the array and b. do you think it may > > severely affect the time it takes for raidreconf to finish? > > It *should* be safe. But as you increase the complexity of the > operations > that raidreconf has to perform, you increase the chance of hitting a bug > that I don't know about... I would try it, but keep good backups :) > > It shouldn't significantly increase the time raidreconf takes to run, as > it does all of it's work in one pass. > > > > > After I write this, I will also try running raidreconf for a > > chunk-resize on this now-110 gb array, see how long it takes and report > > tomorrow. > > Please let me know about the memory/request numbers OK I tried the chunk resizing, I have attached all the output from raidreconf. I did something a little out of the ordinary: converted from a 16 kb chunk-size to 128 kb chunk-size. I don't know if this could have affected what happened. Is 128 kb a usable chunk-size? As far as file size efficiency is concerned, 128 kb is still ok, the target filesystem (the one I plan to update soon) is reiserfs with a default 4k block size, but the files are considerably large. Is the conversion from 16k to 128k somewhat obsurd? Crazy? Too much? Impossible? :) Now, as to what happened. First of all, the memory/request numbers: Detected 224056 KB of physical memory in system A maximum of 1436 outstanding requests is allowed I don't know how that translates in memory usage, however it was using about 30 mb of memory most of the time, when I was checking on it. Also, as you can see in the log, it says: I will SHRINK your old device /dev/md0 of 6863248 blocks to a new device /dev/md0 of 6863240 blocks using a block-size of 16 KB The old and new raidtab were identical, apart from the chunk-size setting. As you can see, the new device it tried to make is 8 blocks smaller than the first one, and that is strange by itself, I think... Could the reason be the chunk-size change? Then at about 80% of the process, after about it ran out of memory. I started it around 11 PM, and at 8 AM it was at about 60%. All this on the same 110 GB md0 I had expanded with raidreconf the night before. Unfortunately I wasn't monitoring the process at the time this happened, and when I got back everything was normal, cpu load and mem usage, and there were only these messages on the terminal. So I don't really know what happened, however the box wasn't running anything else cpu or memory intensive, only raidreconf. Now as for what you replied to my other e-mail, about raidreconf's behavior if it comes across bad sectors and can't read from or write to them properly, you are right; the best it could/should do is retry a few times and if it fails, just mark the block done and move on. The filesystem will have some errors, but hopefully they will only affect a very small number of blocks. If raidreconf aborts, then u probably need to mkraid and start from scratch, all over again, with a blank filesystem. So an erroneous fs is obviously much better than that of course :) That's all for now. Thanks again Jakob and everyone for your help and sharing your experience with raidreconf and these issues :) Best regards, Cajoline Leblanc cajoline at chaosengine dot de - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
