Messages in this thread | | | Date | Tue, 12 Jan 2010 11:59:48 -0500 | From | Ric Wheeler <> | Subject | Re: [PATCH] extend e2fsprogs functionality to add EXT2_FLAG_DIRECT option |
| |
On 01/12/2010 11:56 AM, Eric Sandeen wrote: > 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
It actually could produce some nastier issues where it would work a bit, the bad data gets flushed back to the backing store and then your O_DIRECT read would be broken.
Also, for normal users of e2fsprogs, they should never bypass the cache...
ric
| |