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

[Michael Tokarev]

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:

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

By the way, is it 2.6.27-specific (the kernel) or 2.5-specific
(unionfs release)?

Thanks!

/mjt