On Fri, Nov 14, 2014 at 9:55 AM, Jordi Pujol Palomer <jordipujolp@xxxxxxxxx> wrote: > EL Mon, 10 Nov 2014 10:09:54 +0100 > Miklos Szeredi <miklos@xxxxxxxxxx> escrigué: > >> Maybe it wasn't clear, but the number of lower layers isn't limited by >> FILESYSTEM_MAX_STACK_DEPTH, > sorry, you have been clear, it's me that have not explained the purpose > of that patch. This idea is also valid for the main overlayfs > development. > Consider that we have an encrypted partition and a live OS that > uses overlayfs and works over it, when the OS is started already > reaches the maximum stacking depth (2). Also, hardcoding parameters > into the code may be annoying because a change implies creating and > mantaining patches, otherwise when the parameter is configurable we can > change it in a config value. Before allowing a change to FILESYSTEM_MAX_STACK_DEPTH we'd need to analyze the kernel stack usage of anything taking part in the filesystem stack. Not something that can be expected of users before they set a kernel config variable. 'Course we can change overlayfs and/or ecryptfs to use a new context for operations done on underlying layers. Not sure how much work that would be... > Also, I include a patch to explain better my first statement, > would say lowerdirs has extended the functionality of lowerdir, > therefore we can discard the lowerdir case that only works with one > lower layer and rename lowerdirs to lowerdir. It's more simple and all > the functionality is preserved. Yeah. But we also need some escaping in 'lowerdir=' argument to allow filenames with comma and colon. Current patch doesn't yet have that, but will work on it. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
