[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Replacing aufs with overlayfs



Hi,

intrigeri wrote (11 Dec 2014 13:13:43 GMT) :
> Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) :
>> Please try the Linux 3.18 packages from experimental (they're not there
>> yet, but should be soon) and check that overlayfs does what you need.

> Thanks. I'll test it for Tails' usecases (that use aufs a bit more
> than most other live systems, e.g. our incremental upgrades features
> uses it) once I find the time to.

Here are the results of our preliminary investigations:

1. Due to overlayfs' stack depth limit of 2, until support more than
   one read-only lower layer is completed, overlayfs breaks
   live-boot's SquashFS stacking feature; Tails "automatic upgrades"
   rely on this feature. The current overlayfs maintainer says it is
   the "top feature request", and has been working on it recently
   (https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00079.html).
   The code lives in
   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
   (branch overlayfs-next, currently).

   Later on the same thread, there are also patches
   (https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00088.html)
   to make the stack depth limit configurable at runtime, but it was
   deemed risky by the overlayfs maintainer without more work to check
   that the stack will be safe. So, our best bet right now seems to
   wait for the >1 read-only lower layer feature.

2. Whiteouts support *should* work when using SquashFS (for
   non-directories, using a char device; for directories, using
   a xattr to make them opaque). Not tested yet, though. We also rely
   on this feature for Tails "automatic upgrades".

Is it an option to get aufs back into the Debian kernel until #1 is
completed and reaches mainline? (I could understand that you want to
add a deadline if you make such a promise, of course :)

Cheers,
-- 
intrigeri


Reply to: