Hi, On 2010-02-16 20:18, Christoph Hellwig <hch@lst.de> wrote: > Hmm, it really does look like the typical write cache corruption. > > Looking a bit at the loop driver as suspsect I think I know what the > problem is: > > - loop writes data either using the address_space operations, or > using ->write, but it never calls does the O_SYNC processing > (just ->fsync in modern kernels, but a little different in 2.6.26) > > So when using loop data simply gets written into the page cache, but > there is no guarantee it ever goes out to disk. How could it end up in the page cache for this setup? There is no filesystem layer below the loop device. Any write that reaches the loop device is passed through to lvm, then md and finally the disk. Are you saying that there is extra caching going on at the lvm or md layers? > This bug is still present in latests upstream - a patch to introduce > barrier support calling ->fsync went in a while ago but caused > mysterious lockups and was reverted, with the patch author never > coming back to try to figure it out. That's really unfortunate. Philipp
Attachment:
signature.asc
Description: Digital signature