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
--
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
