On Wed, Jul 12, 2017 at 2:46 PM, Eryu Guan <eguan@xxxxxxxxxx> wrote: > On Wed, Jul 12, 2017 at 02:08:56PM +0300, Amir Goldstein wrote: >> On Wed, Jul 12, 2017 at 1:47 PM, Eryu Guan <eguan@xxxxxxxxxx> wrote: >> > On Tue, Jul 11, 2017 at 10:52:06PM +0300, Amir Goldstein wrote: >> >> Expect EBUSY when trying to mount overlay when: >> >> - Upper dir is in-use by another overlay mount >> >> - Work dir is in-use by another overlay mount >> >> >> >> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> >> > >> > From patch 2/5, seems this behavior requires inode index feature to be >> > enabled, and now test fails on old kernels for me. Is this expected? >> > >> >> From my cover letter: >> "The new test overlay/036 checks for new overlay mount behaviors related >> to exclusivity of upper and work dirs among overlay mounts. This test >> is expected to fail on upstream kernel, but for a good reason, because >> the mount configurations that it tests (sharing upper dir among two >> overlay mounts) are not wise at all." >> >> So the answer is yes, this is expected and also does not depend >> on index feature. > > I usually read the cover letter (I saved it in my 'review' mailbox along > with patches to review), but somehow I forgot about it this time.. > >> >> I know this is a bit confusing, but inode index enforces that 2 >> *subsequent* overlay >> mount don't reuse the same upper/work dir with different lower/upper. >> The test that checks this behavior is overlay/037, still on my >> overlayfs-devel branch. >> >> overlay/036 verifies that 2 *concurrent* overlay mount don't reuse the same >> upper/work dir. The is enforced by overlayfs-next regardless on index feature. >> A setup like this will cause troubles in old kernel as well, but mount >> will not detect it. > > Thanks for the explanation! The commit log and test description don't > provide enough background information. If you could resend with detailed > explanation on the test, that'd be great! > No problem. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
