Michal Novotny wrote: > On 01/12/2010 05:50 PM, Ric Wheeler wrote: >> On 01/12/2010 11:43 AM, Michal Novotny wrote: >>> On 01/12/2010 05:38 PM, Christoph Hellwig wrote: >>>> Ok, I looked at the issue. The problem is that the Xen backend drivers >>>> are (as expected) utterly braindead and submit bios directly from the >>>> virtualization backed without using proper abstractions and thus >>>> bypassing all the cache coherency features in the fileystems (the block >>>> device nodes are just another mini-filesystem in that respect). So >>>> when you first have buffered access in the host pages may stay in cache >>>> and get overwritten directly on disk by a Xen guest, and once the guest >>>> is down the host may still use the now stale cached data. >>>> >>>> I would recommend to migrate your cutomers to KVM which uses the proper >>>> abtractions and thus doesn't have this problem. There's a reason after >>>> all why all the Xen dom0 mess never got merged to mainline. >>> So, do you think the problem is in the Xen backend drivers and to make >>> it working right in Xen the driver fix is needed? >> >> If XEN drivers by pass the normal IO and FS stack on the host, then I >> can understand why the hack to e2fsprogs works but it does not seem >> like a good fix. >> >> Specifically, the data will continue to be cached (and if dirty, might >> be written back to the storage eventually). >> >> If we need a work around, you need to drop VM caches for that device >> before you update the guest's files and possibly again afterwards (and >> make sure that nothing pulls the data into cache during the operation). >> >> Basically, this sounds like the backend drivers are doing something >> really, really dangerous.... >> >> ric >> > Ok, so you think this is not good to do this patch for e2fsprogs for > direct access support? The only things we could do now is to fix the > backend drivers or create a workaround to drop caches? I need to discuss > this further with guys in my team... I do think that patching it up in e2fsprogs is unnecessarily invasive; it's fixing it at the wrong spot. Any block dev IO from the host is dangerous; fixing it only in e2fsprogs for this one case doesn't seem like the right course of action. -Eric > Thanks, > Michal > -- > 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 -- 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
