Re: overlayfs v22 on kernel 3.15.5

Re: overlayfs v22 on kernel 3.15.5

[Miklos Szeredi]

On Wed, Jul 23, 2014 at 1:40 PM, Klaus Kreil <klaus.kreil@univie.ac.at> wrote:
> >
>> Is there some hint in the dmesg output?
>>
> The messag from dmesg reads as follows:
> [    1.323319] overlayfs: failed to resolve '/.work': -2
>
> Now that I find strange because an ls -la /mnt/root_rw from the emergency
> shell started from my initramfs looks as follows:
> # ls -la /mnt/root_rw/
> total 52
> drwxr-xr-x   11 0        0             4096 Jul 21 22:57 .
> drwxr-xr-x    5 0        0                0 Jul 20 23:36 ..
> drwxr-xr-x    2 0        0             4096 Jul 20 23:26 .work
> drwxr-xr-x    2 0        0             4096 Feb 25 23:36 dev
> drwxr-xr-x    7 0        0             4096 Jul 21 22:31 etc
> drwxr-xr-x    3 0        0             4096 Mar  3 21:10 lib64
> drwx------    2 0        0            16384 Feb 25 23:28 lost+found
> drwx------    2 0        0             4096 May 29 13:01 root
> drwxr-xr-x    2 0        0             4096 Jul 21 22:30 run
> drwxrwxrwt    4 0        0             4096 Jul 21 22:31 tmp
> drwxr-xr-x    6 0        0             4096 Apr 25 18:47 var
>
> To me this shows that the directory actually exists ... although the error
> message states that it "failed to resolve" and not "No such file or
> directory" or a similar message.
>
> The mount command from within the initramfs (all on one line) looks as
> follows:
> mount -t overlayfs overlayfs -o
> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw,workdir=/.work /mnt/root
>
> and the output from the mount command (also from within the rescue-shell):
> # mount
> none on /dev type devtmpfs (0)
> none on /proc type proc (0)
> none on /sys type sysfs (0)
> /dev/xvda1 on /mnt/root_ro type ext4 (ro,noatime)
> /dev/xvda3 on /mnt/root_rw type ext4 (noatime,user_xattr,acl)
>
> So I am still somehow at loss and don't know where to go from here.
>
> Thanks again and best regards,
>
> Klaus
>
> P.S. Do you want me to move this discussion the the mailing list?
>

Re: overlayfs v22 on kernel 3.15.5

[Miklos Szeredi]

On Wed, Jul 23, 2014 at 1:48 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Wed, Jul 23, 2014 at 1:40 PM, Klaus Kreil <klaus.kreil@univie.ac.at> wrote:
>> >
>>> Is there some hint in the dmesg output?
>>>
>> The messag from dmesg reads as follows:
>> [    1.323319] overlayfs: failed to resolve '/.work': -2

You need to give absolute paths:

mount -t overlayfs overlayfs -o
lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
/mnt/root

Thanks,
Miklos

Re: overlayfs v22 on kernel 3.15.5

[Klaus Kreil]

On Mi, 23.07.2014, 13:50, Miklos Szeredi wrote:
> On Wed, Jul 23, 2014 at 1:48 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Wed, Jul 23, 2014 at 1:40 PM, Klaus Kreil <klaus.kreil@univie.ac.at>
>> wrote:
>>> >
>>>> Is there some hint in the dmesg output?
>>>>
>>> The messag from dmesg reads as follows:
>>> [    1.323319] overlayfs: failed to resolve '/.work': -2
>
> You need to give absolute paths:
>
> mount -t overlayfs overlayfs -o
> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
> /mnt/root
>
Thanks Miklos,
I had tried that before, but that did not/does not work as well. The new
command (adjusted to my environment and from within the rescue-shell and
all within a single line) was:
# mount -t overlayfs overlayfs -o
lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw,workdir=/mnt/root_rw/.work
/mnt/root

The new error message from dmesg now reads:
[ 1369.069178] overlayfs: workdir and upperdir must be separate subtrees

Thanks Klaus

Re: overlayfs v22 on kernel 3.15.5

[Miklos Szeredi]

On Wed, Jul 23, 2014 at 1:57 PM, Klaus Kreil <klaus.kreil@univie.ac.at> wrote:

>> You need to give absolute paths:
>>
>> mount -t overlayfs overlayfs -o
>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
>> /mnt/root
>>
> Thanks Miklos,
> I had tried that before, but that did not/does not work as well. The new
> command (adjusted to my environment and from within the rescue-shell and
> all within a single line) was:
> # mount -t overlayfs overlayfs -o
> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw,workdir=/mnt/root_rw/.work
> /mnt/root
>
> The new error message from dmesg now reads:
> [ 1369.069178] overlayfs: workdir and upperdir must be separate subtrees

Exactly. Observe that I used upperdir=/mnt/root_rw/upper.

Thanks,
Miklos

Re: overlayfs v22 on kernel 3.15.5

[Klaus Kreil]

On Mi, 23.07.2014, 14:02, Miklos Szeredi wrote:
> On Wed, Jul 23, 2014 at 1:57 PM, Klaus Kreil <klaus.kreil@univie.ac.at>
> wrote:
>
>>> You need to give absolute paths:
>>>
>>> mount -t overlayfs overlayfs -o
>>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
>>> /mnt/root
>>>
>> Thanks Miklos,
>> I had tried that before, but that did not/does not work as well. The new
>> command (adjusted to my environment and from within the rescue-shell and
>> all within a single line) was:
>> # mount -t overlayfs overlayfs -o
>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw,workdir=/mnt/root_rw/.work
>> /mnt/root
>>
>> The new error message from dmesg now reads:
>> [ 1369.069178] overlayfs: workdir and upperdir must be separate subtrees
>
> Exactly. Observe that I used upperdir=/mnt/root_rw/upper.
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?
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.

If that's the case, I guess lost+found should nevertheless stay in the
real root directory of the upperdir?

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.

Thanks again for your help,

Klaus

Re: overlayfs v22 on kernel 3.15.5

[Miklos Szeredi]

On Wed, Jul 23, 2014 at 2:15 PM, Klaus Kreil <klaus.kreil@univie.ac.at> wrote:
> On Mi, 23.07.2014, 14:02, Miklos Szeredi wrote:
>> On Wed, Jul 23, 2014 at 1:57 PM, Klaus Kreil <klaus.kreil@univie.ac.at>
>> wrote:
>>
>>>> You need to give absolute paths:
>>>>
>>>> mount -t overlayfs overlayfs -o
>>>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw/upper,workdir=/mnt/root_rw/work
>>>> /mnt/root
>>>>
>>> Thanks Miklos,
>>> I had tried that before, but that did not/does not work as well. The new
>>> command (adjusted to my environment and from within the rescue-shell and
>>> all within a single line) was:
>>> # mount -t overlayfs overlayfs -o
>>> lowerdir=/mnt/root_ro,upperdir=/mnt/root_rw,workdir=/mnt/root_rw/.work
>>> /mnt/root
>>>
>>> The new error message from dmesg now reads:
>>> [ 1369.069178] overlayfs: workdir and upperdir must be separate subtrees
>>
>> Exactly. Observe that I used upperdir=/mnt/root_rw/upper.
> 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 ---

> 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.

> If that's the case, I guess lost+found should nevertheless stay in the
> real root directory of the upperdir?

Yes.

>
> 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,
Miklos

Re: overlayfs v22 on kernel 3.15.5

[Klaus Kreil]

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