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" <[EMAIL PROTECTED]>
To: "Stan Franker jr" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2007 3:47 AM
Subject: Re: [Unionfs] (no subject)
In message <[EMAIL PROTECTED]>, "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 [EMAIL PROTECTED]).
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/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
