15.08.2011 00:57, Michael Tokarev пишет: > 13.08.2011 20:02, Tao Ma wrote: >> From: Tao Ma <boyu.mt@xxxxxxxxxx> >> >> Hi Michael, >> could you please check whether this patch work for you? > > With this patch applied to 3.0.1 I can't trigger the issue anymore, > after several attempts -- the system just works as it shold be. > I'm not sure this is the right fix or it's just my testcase isn't > as good as it can be... ;) Well, I found a way to trigger data corruption with this patch applied. I guess it's not fault of this patch, but some more deep problem instead. The sequence is my usual copy of an oracle database from another place and start it. When oracle starts doing it's direct-I/O against its redologs, we had problem which is now solved. But now I do the following: I shutdown the database, rename the current redologs out of the way and copy them back into place as new files. And start the database again. This time, oracle complains that the redologs contains garbage. I can reboot the machine now, and compare old (renamed) redologs with copies - they're indeed different. My guess is that copy is done from the pagecache - from the old contents of the files, somehow ignoring the (direct) writes performed by initial database open. But that copy is somehow damaged now too, since even file identification is now different. Is this new issue something that dioread_nolock supposed to create? I mean, it isn't entirely clear what it supposed to do, it looks somewhat hackish, but without it performance is quite bad. Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
