Erez Zadok: > We are pleased to announce a major new release, Unionfs 2.3. The changes > here from the previous version (2.2.4) are:
Congratulations. > Note that there are two major changes in this release, which is why we > designate it a "major new release." ::: > 2. Based on recommendations we've received while at LSF'08 last month, we've > changed Unionfs to use the vm_operations->fault method, instead of > address_space_operations. This makes unionfs's code smaller, runs > faster, removes a number of potential racy execution paths, and also > closes a couple of bugzilla bugs. This change is significant, but is > only an internal implementation change: it shouldn't change any > user-visible behavior. Note that this change affects unionfs releases > for 2.6.23 and newer kernels only. (Plus, in the next couple of months > we'll be submitting kernel patches to fix the VFS/MM so stackable file > systems can support ->fault more cleanly.) While I don't know what was recommended at LSF'08 last month, I believe that you remember that it is I that suggested this approach to you. <http://marc.info/?l=linux-fsdevel&m=119725691916244&w=2> <http://marc.info/?l=linux-fsdevel&m=119755988904539&w=2> <http://marc.info/?l=linux-fsdevel&m=119766721326870&w=2> So I hope you to title/credit my name and AUFS about this approach in unionfs. And as I wrote before (see the url above), you need to lock to address a race condition in page fault. Junjiro Okajima _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs