On Mon, 29 Jan 2001, Michael Bilow wrote: > Well, if you are getting to the completion of RAID resync, then whatever > problem you are having is not the one that I was reporting in those bugs. > At the time, the behavior if swapping was started during the RAID resync > was a hard system crash with a kernel panic. In no case did this ever > result in actual corruption of the data on the filesystem being resynced, > but that is certainly a possibility. The bugs I reported really were > fixed in the Potato release.
Sorry, for the delay in replying. Your mail hit the nail on the head. I now agree that the problem I saw was not related to the bug-report you had filed. The md0 was OK, it was the ext2fs on the device that was corrupt, badly. > The main exception to this clean interface is that, in emergencies, the > filesystem tools such as e2fsck can be used as a last resort against the > component partitions with RAID totally disabled. This is not the proper > way to recover a broken RAID set, and the raidtools2 utilities should be > used for that. However, if something catastrophic were to happen with the > RAID utilities themselves or the kernel RAID code, provision has been made > for accessing the component partitions directly. This was done through > the simple expedient of putting the RAID-specific information -- the > "persistent superblocks" -- at the end of the component partitions instead > of at the beginning, so that the first 99.999% or so of each component > partition looks to e2fsck as if it has a meaningful ext2 superblock at the > beginning. Yes!!! Added another disk, installed a basic Debian on it, and started trying to find the ext2fs on /dev/hda2 (not /dev/md0). Took quite some time finding a superblock that was usable, but it finally worked. Checked that the data was OK (mostly mail spools), and then backed up, recreated ext2fs on /dev/md0, restored, booted, and WOW! > Note that I am not actually advising you to access the data > this way, but simply advising you of the possibility should all else fail. > (This is also done to allow booting from a RAID component, since clearly > the ROM BIOS has no knowledge of Linux software RAID and Lilo has to get > files loaded within that constraint.) I understand your advice, but I was desperate, and understand ext2 better than RAID. > There are some extensive discussions of all of this in the RAID HOWTO -- > http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/ -- and most of what you > are dealing with is not Debian-specific. As a result, you might be more > likely to get help with a serious problem on the Linux-RAID mailing list. True, but the problem was my wrong diagnosis of the issue, thinking it to be a debian-specific bug. The error I got, (swapper uses obsolete iocts, followed by a panic), seemed to fit your report. Once more, my heartfelt thanks to your support. -- Sanjeev "ghane" Gupta Mob: +65 98551208 dotXtra Pte Ltd Fax: +65 2275776 Singapore email: [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
