Messages in this thread | | | Date | Thu, 16 Aug 2012 15:24:08 +0200 | Subject | Re: [PATCH 08/13] fs: limit filesystem stacking depth | From | Sedat Dilek <> |
| |
On Thu, Aug 16, 2012 at 12:42 PM, Miklos Szeredi <miklos@szeredi.hu> wrote: > Sedat Dilek <sedat.dilek@gmail.com> writes: > >> On Wed, Aug 15, 2012 at 5:48 PM, Miklos Szeredi <miklos@szeredi.hu> wrote: >>> From: Miklos Szeredi <mszeredi@suse.cz> >>> >>> 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 [unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] | |