Re: [PATCH 08/13] fs: limit filesystem stacking depth

[Sedat Dilek]

On Thu, Aug 16, 2012 at 12:42 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> Sedat Dilek <sedat.dilek@xxxxxxxxx> writes:
>
>> On Wed, Aug 15, 2012 at 5:48 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>> From: Miklos Szeredi <mszeredi@xxxxxxx>
>>>
>>> Add a simple read-only counter to super_block that indicates deep this
>>> is in the stack of filesystems.  Previously ecryptfs was the only
>>> stackable filesystem and it explicitly disallowed multiple layers of
>>> itself.
>>>
>>> Overlayfs, however, can be stacked recursively and also may be stacked
>>> on top of ecryptfs or vice versa.
>>>
>>> To limit the kernel stack usage we must limit the depth of the
>>> filesystem stack.  Initially the limit is set to 2.
>>>
>>
>> Hi,
>>
>> I have tested OverlayFS for a long time with "fs-stack-depth=3".
>> The original OverlayFS test-case script  from Jordi was slightly
>> modified (see "testcase-ovl-v3.sh").
>> I have sent my test-results to Andy and Jordi (tested with the
>> patchset from Andy against Linux-v3.4 [1] with Ext4-FS).
>> The attached test-case script *requires* "fs-stack-depth=3" to run
>> properly (patch attached).
>>
>> So, I have 2 questions:
>>
>> [1] FS-stack-limitation
>>
>> Is a "fs-stack-depth>=2" (like "3") critical?
>> Is your setting to "2" just a defensive (and initial) one?
>> Can you explain your choice a bit more as ecryptFS is involved in this
>> limitation, too.
>
> If directly stacking filesystems like this on top of each other
> (ecryptfs is currently the only filesystem that does this in mainline)
> then the call chain can get too long and the kernel stack overflow.
>
> Yes, setting it to 2 is defensive, it would need more stack depth
> analysis to see what an acceptable number would be.
>

Can you describe such an analysis method (in case you need help for testing it)?

>
>> [2] Test-Case/Use-Case scripts
>>
>> It would be *very very very* helpful if you could provide or even ship
>> in the Linux-kernel a test-case/use-case script, Thanks!
>
> Sure, I could add Andy's test script under the tools/ directory.  But I
> don't understand why exactly it needs the stacking depth to be
> increased.
>

No, it was Jordi's test-case script :-).
Unfortunately, my modified version had a brownbag included and will
not run (forgot a comment sign).
v4 attached is included in the atched tarball (see scripts/).

I have added my test-results against a slightly modified Linux-Next
(next-20120816) kernel (see patches/).

All relevant material is in the TAR-XZ archive (see also attached ls-lR.txt).

AFAICS Jordi is creating 3x Upper/Lower/Root dirs/mounts/etc., that's
why a "fs-stack-max-depth=3" is minimum requirement.
( Just FYI: The "LOG-24G" log-file below
TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ has detailed
informations. )

Hope this helps you.

- Sedat -

> Thanks,
> Miklos
.:
total 20
drwxr-xr-x 9 wearefam wearefam 4096 Aug 16 15:06 TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:06 kernel-config
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:10 logs
-rw-rw-r-- 1 wearefam wearefam    0 Aug 16 15:11 ls-lR.txt
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:11 patches
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:05 scripts

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq:
total 4736
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 COW-r0b
-rw-r--r-- 1 wearefam wearefam 134217728 Aug 16 14:54 COWFILE-ZdO
-rw-r--r-- 1 wearefam wearefam    127944 Aug 16 14:54 LOG-24G
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 ROOT-RO-DmL
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 ROOT-RO-dxr
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 ROOT-sxo
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 UPPER-OCW
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 UPPER-ULU
drwxr-xr-x 2 wearefam wearefam      4096 Aug 16 14:54 UPPER-nJm
-rw-r--r-- 1 wearefam wearefam      4096 Aug 16 14:54 WORK-6S5.squashfs
-rw-r--r-- 1 wearefam wearefam      4096 Aug 16 14:54 WORK-gSq.squashfs
-rw-r--r-- 1 wearefam wearefam      4096 Aug 16 14:54 WORK-wBd.squashfs

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/COW-r0b:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-RO-DmL:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-RO-dxr:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-sxo:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-OCW:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-ULU:
total 0

./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-nJm:
total 0

./kernel-config:
total 144
-rw-r--r-- 1 wearefam wearefam 145381 Aug 16 13:42 config-3.6.0-rc1-next20120816-1-iniza-generic

./logs:
total 56
-rw-rw-r-- 1 wearefam wearefam 54421 Aug 16 15:09 dmesg_3.6.0-rc1-next20120816-1-iniza-generic_HIDDEN.txt

./patches:
total 136
-rw-rw-r-- 1 wearefam wearefam 137929 Aug 16 12:47 3.6.0-rc1-next20120816-1-iniza-generic.patch

./scripts:
total 8
-rwxr-xr-x 1 wearefam wearefam 4925 Aug 16 14:58 testcase-ovl-v4.sh

Attachment: overlayfs-v14_tested-by-dileks.tar.xz
Description: Binary data

Attachment: overlayfs-v14_tested-by-dileks.tar.xz.sha256sum
Description: Binary data