In message <[EMAIL PROTECTED]>, 
"=?ISO-8859-1?Q?P=E1sztor_L=E9n=E1rd_Zolt=E1n?=" writes:

> Hi,
> 
> I am using unionfs 2.1.10 (for 2.6.23.8).
> The unionfs root has two layers, a read-only nfs filesystem and a tmpfs.
> When I doing some test i got this:
> 
> [EMAIL PROTECTED]:~# mkdir /var/lib/misc/testdir
> mkdir: cannot create directory `/var/lib/misc/testdir': Read-only file
> system
> [EMAIL PROTECTED]:~# mkdir /var/lib/misc/testdir
> mkdir: cannot create directory `/var/lib/misc/testdir': Read-only file
> system
> [EMAIL PROTECTED]:~# touch /var/lib/misc/testdir
> [EMAIL PROTECTED]:~# rm /var/lib/misc/testdir
> [EMAIL PROTECTED]:~# mkdir /var/lib/misc/testdir && echo OK
> OK
> [EMAIL PROTECTED]:~#
> 
> It looks like a problem within unionfs COW algoritm. If the parent director=
> y
> not exists in the COW layer the mkdir failed.
> When the parent directory (/var/lib/misc) exists in the COW layer (after
> touching a file on it) the subdirectory can created.
> It is a real bug, or I miss something?
> 
> thx,

Lenard, I think I may have found your problem.  My guess is that you're
using a readonly-exported NFS partition, right?  In your followup email you
listed the sequence of mounts you've used as follows:

> mount -t tmpfs none /1
> mount -t nfs st1:/base /2
> mount -t unionfs -o dirs=/1=rw:/2=nfsro unionfs /root

This puzzled me.  You're using the 'nfsro' option, which I *know* I've
removed a while back.  It was valid only for unionfs 1.x, but in unionfs
2.1, it's no longer needed -- just plain 'ro' works the same whether its nfs
or not.  So how come unionfs 2.x allowed the "unknown" nfsro option to be
accepted?  It was an option-parsing bug, which I fixed, and which would be
in unionfs-2.1.11 when I release it.  From now on, unrecognized branch-mode
options would not default to 'rw' but would produce a mount-time error.

The fix to your problem is to use the =ro option:

# mount -t unionfs -o dirs=/1=rw:/2=ro unionfs /root

With that, unionfs will recognize that the /2 directory is a readonly
branch, and that would cause copy-ups to take place normally, and you
shouldn't be getting an EROFS error from mkdir/touch, etc.  Please give this
a try and let me know how it works for you.

Thanks,
Erez.
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to