Re: [RFC] Tux3 for review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave,

This is to address your concern about theoretical interaction between direct IO and Tux3 page fork.

On Monday, May 19, 2014 10:41:40 PM PDT, I wrote:
Except that Direct IO impacts on the design of the page forking code
(because of how things like get_user_pages() need to be aware of
page forking). So you need to have direct IO working to demonstrate
that the page forking design is sound.....

Page fork only affects cache pages, so the only interation with direct IO is when the direct IO is to/from a mmap. If a direct write races with a programmed write to cache that causes a fork, then get_user_pages may pick up the old or new version of a page. It is not defined which will be written to disk, which is not a surprise. If a direct read races with a programmed write to cache that causes a fork, then it might violate our strong ordering, but that is not a surprise. I do not see any theoretical oopses or life cycle issues.

So Tux3 may allow racy direct read to violate strong ordering, but strong ordering would still be available with proper application sequencing. For example, direct read to mmap followed by msync would be strongly ordered.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux