Mailinglist Archive: yast-devel (100 mails)

< Previous Next >
[yast-devel] overlayfs - why you might not use it
Now that overlayfs went into the 3.18 kernel I've had a look if this could
be used in our installation environment.


= what we need =

We have to combine several ro (squashfs) filesystems into the root fs. And
the final fs should be writable. Also, it should be possible to easily add
and remove fs images.


= what we currently do =

A script integrates new filesystem images by adding symlinks as needed.


= what overlayfs (currently) can do =

First, here's how to use it:

mount -t overlay overlay -olowerdir=/foo,upperdir=/bar,workdir=/xxx /mnt

where /xxx must be on the same fs as /bar but not below /bar. (That's why
upperdir must be a writable fs atm, btw.)

You can combine exactly *two* filesystems the 'upper' one must be writable. (Doc says you can use two ro filesystems but that is not true atm and
there's a note in the sources that they might fix this.)

There's no way to combine more than two filesystems except by step-by-step
doing overlay mounts. This seems not much of a problem at first but in
practice is quite annoying as there are conditions to fulfill; namely you
have to have a 'work' directory in the upper fs that must be a separate
subtree from the '/' dir in the upper fs.

So you would have to make every squashfs writable first by overlaying it
with a tmpfs. And then add it to the existing stack. We combine 8 images atm
in Factory, so that would be about 16 overlay mounts. Plus you cannot easily
unmount parts of this beast as any process rw-opening a file and holding it
open (say, even some log or tmp) will block the umount. Plus anything you
logged into log files will be lost when you unmount the upper level.

This construction seems to be too impractical to me.


= conclusion =

Not yet.


Steffen
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages