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
