On Tue, Apr 03, 2007 at 09:03:50AM -0700, Badari Pulavarty wrote: > On Tue, 2007-04-03 at 11:31 +0200, Nick Piggin wrote: > > On Tue, Apr 03, 2007 at 02:08:53AM +0200, Nick Piggin wrote: > > > > BTW, I will take a shot at ext4 tomorrow. > > > > > > Thanks, so long as you think ext3 is looking OK? > > > > > > BTW. is it a known issue that ext3 fails fsx-linux? (I tried 2.6.21-rc3 > > > IIRC, and ordered and writeback both eventually failed I think). ext2 > > > does not. > > > > Well I just tested, and it is not fixed by the recent patch to revert > > ext3_prepare_failure.... > > > > Is this a known issue? Is it an fsx-linux shortcoming? It is fairly > > surprising because it basically makes it impossible to test ext3 > > changes with that nice tool :( I can submit the traces if anyone is > > interested, however I can reproduce in UML on an ext3 writeback > > filesystem with no arguments (except the filename). > > > > I haven't seen an fsx failure recently. I ran 4 copies of fsx > on 2.6.21-rc5 and 2.6.21-rc5+aops, without any problems for > 12+ hours. What am I missing ? Well this is in UML and mounted on loopback, so it could be a failure in the driver stack somewhere. However ext2 is completely solid, so I did suspect ext3. In my configuration, some IO operations that would take a reasonable amount of time on a real system will complete much more quickly. There might be an issue there? Using a ramdisk or loop over tmpfs might produce something. I'll ping you again if I can reproduce outside of UML. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
