I don't have an explanation for the ext3 problem which you saw.
It's conceivable that 2.5.13 was leaving dirty buffers around after
they were "deleted", and that fsync grabbed them via the i_dirty_buffers
back door, and wrote them where they shouldn't have been written.
But they wouldn't have been mapped anywhere...
So I still need to try to reproduce that one. If you could have
another shot, it would be appreciated. But if it _does_ work OK,
I can't say it's fixed until I know what caused the 2.4.13 failure.
ext3 is very sensitive to what is going on in buffer.c. There's
a lot of tension in there between the desire to share code and
the desire to not be damaged by changes in the code which we share.
Generally, ext3 with data=journal is not happy at present.
Partly because it contains assertions of things which aren't true
Partly because of a known problem in ext3: assertion failure at
transaction.c:606. Stephen has a fix for this which we need to
wiggle into 2.4. For some reason, the 2.5 changes are triggering
it much more easily.
I'll spend a few hours this week trying to resurrect data=journal,
but if that doesn't work out I think I'll just turn it off for the
while, make it emit a warning and use data=ordered.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/