Re: overlayfs v22 on kernel 3.15.5

["Klaus Kreil" <klaus.kreil@univie.ac.at>]

On Mi, 23.07.2014, 15:33, Miklos Szeredi wrote:
> On Wed, Jul 23, 2014 at 2:15 PM, Klaus Kreil <klaus.kreil@univie.ac.at>
> wrote:
>> I see what you mean and I have to admit, that slipped my eye.
>>
>> This however triggers an additional question: Would this now require me
>> to
>> create an new "virtual" root directory (in your case named "upper") on
>> my
>> upperdir filesystem and move everything that was in the real root of the
>> existing upperdir filesystem to the new virtual root directory?
>
> Yes.  And in adition you need to run the following script (upperdir
> given as a single argument) to convert whiteouts from the old format
> to the new:
>
> --- overlayfs-fixup.sh ---
> #! /bin/bash
>
> upper=$1
> tmpdir=`mktemp -d`
> tmp=$tmpdir/wh
> find "$upper" -type l -print0 | while IFS= read -r -d $'\0' name; do
>         iswh=`getfattr -h -ntrusted.overlay.whiteout --only-values
> "$name" 2> /dev/null`
>         if test "$iswh" = y; then
>                 echo "changing whiteout <$name> from symlink to chardev"
>                 mknod -m0 $tmp c 0 0
>                 mv -f $tmp "$name"
>         fi
> done
> rmdir $tmpdir
> --- cut here ---
>
I had already seen the need to deal with whiteouts somewhere, but that
wasn't an issue for me because currently there are no whiteouts in my
upperdir. It only contains changed files.
After having given the new requirements some thought I, however, consider
no longer being able to use the root of my upperdir filesystem is
something I do not really like. What's the reason that this has changed
between v21 and v22 and what are the advantages? Currently I only see a
few drawbacks, but I might not see the full picture ...
In my view the old approach was much clearer for overlaying one filesystem
on top of another r/o filesystem as the old approach guaranteed that a
path to any file on each filesystem was identical resulting in offline
maintenance scripts being applicable to both the lower- and the upperdir
without change.
And in my view that was (one of) the real beatuies of overlayfs ...
>> In other words now - and contrary to the old behaviour - overlaying one
>> root directory of a filesystem onto another root directory of another
>> filesystem is no longer possible.
>
> Not at this time.
Are there any plans to revert back to the old behaviour of being able to
use the real root of the upperdir filesystem during the mount in order to
again achieve what I have described above?
>
>> If that's the case, I guess lost+found should nevertheless stay in the
>> real root directory of the upperdir?
>
> Yes.
Thanks. That was sort of expected ...
>
>>
>> Furthermore that would als mean that the workdir is never visible from
>> within the combined tree and therefore I could go away with the .work
>> and
>> rename the workdir to work.
>
> Yes.
>
Thanks again

Klaus