[Unionfs] (no subject)

[Stan Franker jr]

Thank you very much for your informative reply. The =rw argument did the 
trick, I had been using an older version of unionfs (I believe 1.3) and afai 
can recall I was able to do a =ro back then. Never considered that to be the 
problem.

The stability of 1.3 was actually great until I recently was getting some 
very strange errors. Lots of dma timouts when disks were confronted with 
heavy I/O loads, no idea if it was actually unionfs related but the problem 
is gone now. I figured it was time to see if a newer version + a new kernel 
would help. So far its as stable as ever so I don't think I will be using 
unionfs 2.0 since my linux skills are basic at best and well...... you know 
what they say about changing a winning game :).

Thanks again for the help.

Regards,

Stan Franker

----- Original Message ----- 
From: "Erez Zadok" <ezk at cs.sunysb.edu>
To: "Stan Franker jr" <s-frank at dds.nl>
Cc: <unionfs at fsl.cs.sunysb.edu>
Sent: Monday, July 09, 2007 3:47 AM
Subject: Re: [Unionfs] (no subject)


> In message <001601c7c077$69b9e460$020314ac at mobile>, "Stan Franker jr" 
> writes:
>
>> when issueing the command: mount -t unionfs -o 
>> dirs=/mnt/disk1=ro:/mnt/disk2=ro unionfs /ftp/site/archive
>>
>> i get:
>>
>> mount: wrong fs type, bad option, bad superblock on unionfs-mv,
>>        missing codepage or other error
>>        In some cases useful info is found in syslog - try
>>        dmesg | tail  or so
>>
>> dmesg output is:
>>
>> NET: Registered protocol family 10
>> lo: Disabled Privacy Extensions
>> IPv6 over IPv4 tunneling driver
>> eth0: no IPv6 routers present
>> Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
>> NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
>> NFSD: starting 90-second grace period
>> unionfs_read_super: error while parsing options (err = -22)
>> unionfs_read_super: error while parsing options (err = -22)
>> unionfs_read_super: error while parsing options (err = -22)
>>
>> i'm using
>>
>> Linux debian 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 
>> GNU/Linux
>>
>> with unionfs-1.4. Is this a compatibility issue? According to
>> http://www.am-utils.org/project-unionfs.html unionfs-1.4 is compatible
>> with kernel 2.6.18.8 which is obviously newer then what i am using.
>>
>> regards,
>>
>> Stan
>
> Stan, it looks like you're trying to produce a real-only union, because 
> all
> your branches are marked as readonly.  In unionfs, if you want a readonly
> union, you must pass the "-o ro" option to /sbin/mount; otherwise, you 
> can't
> have the leftmost branch be readonly (unionfs needs a writable branch to
> copyup to).
>
> Unfortunately, unionfs 1.x doesn't give you a good message saying this. 
> In
> unionfs 2.0, we fixed it so that at least the kernel message you get will
> tell you how to produce a readonly union the right way.
>
> In case you're wondering why can't we just detect that the leftmost branch
> is set to "=ro" and treat the whole union as a readonly union -- we can't.
> The kernel and esp. the VFS do certain special things only when a user
> passes "-o ro" to the mount(2) syscall; by the time a file system like
> unionfs detects that a leftmost branch has been set to readonly, it's too
> late to muck with the VFS's own state.
>
> BTW. if you're using 2.6.18, I'd recommend you use our latest unionfs 2.0
> backport which we made recently.  Unionfs 2.0 is much more stable and
> functional than 1.x.  If you do move up to 2.0, we'd love to hear some
> feedback from you on how it works for you.
>
> Cheers,
> Erez.
> _______________________________________________
> unionfs mailing list: http://unionfs.filesystems.org/
> unionfs at mail.fsl.cs.sunysb.edu
> http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs