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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85wq5k208r....@boum.org
