[Unionfs] unionfs 1.x - 2.x with ro NFS, copyupuid, etc.

Erez Zadok ezk at cs.sunysb.edu
Sun Jul 8 21:35:54 EDT 2007


In message <CB5EDA8FB6FB99469D660137D6EFBEC96E5742 at xmb-sjc-22e.amer.cisco.com>, "Caleb Mulford \(cmulford\)" writes:

> Hi,
>    We have been trying out unionfs here, testing the waters, and found
> unionfs 1.0.14 and 1.1.5 to be mostly stable, and almost usable for our
> needs.  But there were a couple problems, one with stability where
> running multiple gmakes simultaneously would lock up the system or use
> all available memory and kill off one of the gmakes.  I know these
> gmakes are using all available memory, so the problem is more one where
> we are curious if unionfs uses more RAM or could cause additional
> instability when dealing with memory intensive loads..  

Caleb, this message was held up on our mail server along with a bunch of
spam.  Sorry for the belated reply.

unionfs2 is a lot more stable than 1.x.  I strongly recommend you try that
over unionfs 1.x.

Yes, unionfs, as a stackable file system, does use up more kernel memory:
every object on a lower branch has a corresponding object at the unionfs
layer.  So dentries, inodes, struct files, and even struct pages, are
duplicated.  That is the way layered file systems operate, and is pretty
much necessary.  Nevertheless, consuming more memory, in the worst case,
should result in some reduced performance when there's memory pressure
(i.e., pdflush kicks in more often and such).  It shouldn't cause crashes:
so I suspect the problems you're seeing may be related to using the
less-stable unionfs 1.x.

Here we run parallel gmake's all the time with unionfs 2.0, and we've not
seen any crashes or instabilities due to memory-intensive workloads.

> And the other
> has to do with copyup options with unionfs 2.x and possibly aufs.  As we
> have tried to use both aufs and newer versions of unionfs we ran into
> problems with our mount options.

Can you give us more info?  What mount options you've tried?  What didn't
work?  Which features do you really need (and why)?  (Your subject line
suggests "ro NFS" and "copyupuid", but I'd like to get more details please.)

> I was wondering if there were
> additional resources we could use since the man pages and documentation
> in the kernel and unionfs patches is sometimes inconsistent?  Thank you.

Which documentation is inconsistent: all of the patches we release include
documentation that's in sync with the code.  See the files in
Documentation/filesystems/unionfs/*.txt.  Especially useful is the file
usage.txt, which includes many usage examples.

If you find problems with the docs we have, please let us know and we'll
update the docs.  I realize how frustrating it is to not have documentation,
or worse, inconsistent documentation (I've been there too :-), which is why
we try to keep both code and user docs up-to-date.

> Best Regards,
> Caleb

Cheers,
Erez.


More information about the unionfs mailing list