[Unionfs] OT: access() of fuse unionfs

Bernd Schubert bernd-schubert at gmx.de
Fri Jan 12 11:59:30 EST 2007


Hi,

sorry about my entirely off-topic post, but I don't know where else people
would know about my problem.

For some time already we are using unfs3 (it supports cluster extensions to
files, such as $$IP=abc.def.ghi.jkl$$) to have client specific files
in /etc and /var.
While this works fine for several years already (before unfs3 we were using
clusternfs), it still has limitations.

Using your kernel based unionfs won't work, as we are always doing software
updates on the server, which will always write to one of the unionfs
branches.

I'm just trying to use a fuse based unionfs (funionfs) and while it already
works, I see a problem with the access() call.

In detail we are merging /common/var and /unionfs/var to /var.
The /common/var directory is mounted read-only from the server and I also
specified this as parameter to funionfs. 
The problem is now the access() call, when a client wants to write to a file
which is not yet in its own /unionfs/var branch. E.g. vim, syslogd, etc.
first do a test res = access(path, W_OK). 
In funionfs the funionfs_access() function will now see, that there is
no /unionfs/var/.../somefile and will return the access() call
to /common/var/.../file. 
As you know, this tree is read-only and so access() will return that there's
no write permission.

I'm now looking for a good way how to fix this problem, but I don't like any
of my own ideas comming to my mind.

1) Do a COW operation on access(path, W_OK) to the writable branch and keep
the file.

2) As before, but delete the file after the access() call.

3) Reimplement everything whats in the libc access() and add code to check
if there's also a writable branch.

As I told above, I like none of those ideas and even though I'm already
thinking about it for 1 day, I don't see a better solution.
So I just hope you already had the same problem and maybe you can provide a
better solution :)

Thanks in advance,
Bernd



More information about the unionfs mailing list