[Unionfs] unionfs-2.5_for_2.6.27-rc6 and Kernels 2.6.27 to 2.6.27.4

[Erez Zadok]

In message <49133485.5060905 at msgid.tls.msk.ru>, Michael Tokarev writes:
> Daniel Reichelt wrote:
> > Hi list,
> > 
> > I have an unionfs mount setup like this:
> > 
> > # mkdir br1 br2 rwunion
> > # mount -t nfs -o ro server:/nfsexport /br2
> > # mount -t unionfs -o dirs=/br1=rw:/br2=ro none /rwunion/
> > 
> > So far so good. When I try to add new files or remove files that pre-existed on
> > the ro-nfs branch, that works just fine. However appending/chaning files
> > originating from the ro-nfs branch, I get this:
> > 
> > # ls -la /br1
> > # ls -la /br2
> > -rw-r--r-- 1 root root   55 2008-11-06 04:41 test
> > 
> > # ls -la /rwunion
> > -rw-r--r-- 1 root root   55 2008-11-06 04:41 test
> > 
> > # echo >test
> > bash: test: Permission denied
> 
> This is matches my expirence as well.  Quite annoying sometimes... :)
> 
> F.e., on a unionfs-root with one branch from read-only nfs and
> another on tmpfs:

Are you using this w/ a livecd?  If so, can I get an image to try and some
instrux how to use it?

>   # apt-get update
>   apt: unable to open /var/lib/apt/lists/lock: Permission denied
>   # touch /var/lib/apt/lists/lock
>   # apt-get udpate
>   .. apt goes on successfully ..
> 
> I.e., when opening a file residing on a read-only branch for
> writing, unionfs returns EACCES, but touch'ing etc that file
> makes a copy in a read-write branch, and opening THAT file
> works.  So looks like the open(O_WRITE) case when the file
> is on the ro branch does not work as expected.
> 
> But after thinking about this for a bit... the COW (Copy On Write)
> should really be coW, not coO (copy on open).  IMHO.  I.e., to
> let open(O_WRITE) to succeed, but to create the copy on first
> real write, not on open.  Oh well.

That's what my code aims to do: defer CoW until it's definitely needed.  So
if you open a file w/ O_WRITE, then close it w/o performing any write,
unionfs should NOT be copying up anything.  (That was a fix to a bugzilla
report from a while back.)

Because the permission semantics of unionfs are different than a typical
f/s, I had to use my own version of inode_permission; otherwise I can't
distinguish b/t EROFS cases that should trigger copyups, and other
permission problems that should not trigger copyups.

Anyway, first I need to reproduce the problem you're seeing.  I'm sure the
fix will be a simple one (it's not like this bug is a race condition :-)

Cheers,
Erez.