Question about overlayfs ovl_link

Question about overlayfs ovl_link

[Robin Dong]

Hi, Miklos

We are testing and evaluating overlayfs on our machines now. It is
stable but we feel unsure about the ovl_link.

Imaging using ext4 as upperdir which has a file "hello" and lowdir is
totally empty.

1. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper /overlay
2. cd /overlay
3. ln hello bye

then the overlayfs code will call vfs_link to create a real ext4
dentry for "bye" and create
a new overlayfs dentry point to overlayfs inode (which standed for
"hello"). That means: two
overlayfs dentries and only one overlayfs inode.

now we continue

4. umount /overlay
5. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper
/overlay (again)
6. cd /overlay
7. ls hello bye

then the overlayfs will create two inodes(one for the "hello", another
for the "bye") and two
dentries (each point a inode).That means: two dentries and two inodes.

As above, with different order of "create link" and "mount", the
result is not the same.

My question is: Why not create a new overlayfs inode for "bye" and a
new overrlayfs dentry to point it when user do "ln hello bye" ?


Thanks

-- 
--
Best Regard
Robin Dong

Re: Question about overlayfs ovl_link

[Miklos Szeredi]

Robin Dong <hao.bigrat@gmail.com> writes:

> Hi, Miklos
>
> We are testing and evaluating overlayfs on our machines now. It is
> stable but we feel unsure about the ovl_link.
>
> Imaging using ext4 as upperdir which has a file "hello" and lowdir is
> totally empty.
>
> 1. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper /overlay
> 2. cd /overlay
> 3. ln hello bye
>
> then the overlayfs code will call vfs_link to create a real ext4
> dentry for "bye" and create
> a new overlayfs dentry point to overlayfs inode (which standed for
> "hello"). That means: two
> overlayfs dentries and only one overlayfs inode.
>
> now we continue
>
> 4. umount /overlay
> 5. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper
> /overlay (again)
> 6. cd /overlay
> 7. ls hello bye
>
> then the overlayfs will create two inodes(one for the "hello", another
> for the "bye") and two
> dentries (each point a inode).That means: two dentries and two inodes.

I understand what you are saying but does this have any visible effect?

I mean, is there a way to observe the difference in behavior just from
userspace or the only difference is in the kernel internal objects?

> As above, with different order of "create link" and "mount", the
> result is not the same.
>
> My question is: Why not create a new overlayfs inode for "bye" and a
> new overrlayfs dentry to point it when user do "ln hello bye" ?

Could be done, but I'm interested in a reason for the change.

Thanks,
Miklos

Re: Question about overlayfs ovl_link

[Robin Dong]

在 2012年2月28日 下午4:41，Miklos Szeredi <miklos@szeredi.hu> 写道：
> Robin Dong <hao.bigrat@gmail.com> writes:
>
>> Hi, Miklos
>>
>> We are testing and evaluating overlayfs on our machines now. It is
>> stable but we feel unsure about the ovl_link.
>>
>> Imaging using ext4 as upperdir which has a file "hello" and lowdir is
>> totally empty.
>>
>> 1. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper /overlay
>> 2. cd /overlay
>> 3. ln hello bye
>>
>> then the overlayfs code will call vfs_link to create a real ext4
>> dentry for "bye" and create
>> a new overlayfs dentry point to overlayfs inode (which standed for
>> "hello"). That means: two
>> overlayfs dentries and only one overlayfs inode.
>>
>> now we continue
>>
>> 4. umount /overlay
>> 5. mount -t overlayfs overlayfs -o lowerdir=/lower,upperdir=/upper
>> /overlay (again)
>> 6. cd /overlay
>> 7. ls hello bye
>>
>> then the overlayfs will create two inodes(one for the "hello", another
>> for the "bye") and two
>> dentries (each point a inode).That means: two dentries and two inodes.
>
> I understand what you are saying but does this have any visible effect?
>
> I mean, is there a way to observe the difference in behavior just from
> userspace or the only difference is in the kernel internal objects?
>

We have backported the overlayfs to our kernel (2.6.32) and find out
that when making hard link for a upper file, the kernel will BUG_ON,
the reason is:

After "ln hello bye" (as the example above and imaging file "hello" is
an executive program), there are two overlayfs dentries
point to just one inode. Then we run "./hello", the d_count of "hello"
dentry become 1 (by __d_lookup), and ovl_permission will try to get
the alias
dentry of this inode:

                alias = list_entry(inode->i_dentry.next,
                                   struct dentry, d_alias);
                dget(alias);

but it will find out "bye" dentry and its d_count is zero (because we
get the inode from another dentry--"hello").
It will report BUG_ON when trying to dget a zero d_count dentry in
2.6.32 kernel:

static inline struct dentry *dget(struct dentry *dentry)
{
        if (dentry) {
                BUG_ON(!atomic_read(&dentry->d_count));
                atomic_inc(&dentry->d_count);
        }
        return dentry;
}

There are two ways to fix this problem.
First, traverse all alias of inode to find a non-zero-d_count dentry,
this may be inefficient
Second, create a new overlayfs inode and a new overlayfs dentry in
ovl_link, that will make the result of two actions
("create link" then "mount", or "mount" then "create link") consistent.

So, we are expecting your suggestions

Thanks.

>> As above, with different order of "create link" and "mount", the
>> result is not the same.
>>
>> My question is: Why not create a new overlayfs inode for "bye" and a
>> new overrlayfs dentry to point it when user do "ln hello bye" ?
>
> Could be done, but I'm interested in a reason for the change.
>
> Thanks,
> Miklos



-- 
--
Best Regard
Robin Dong
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about overlayfs ovl_link

[J. R. Okajima]

Robin Dong:
> There are two ways to fix this problem.
> First, traverse all alias of inode to find a non-zero-d_count dentry,
> this may be inefficient
> Second, create a new overlayfs inode and a new overlayfs dentry in
> ovl_link, that will make the result of two actions
> ("create link" then "mount", or "mount" then "create link") consistent.

How about third one (as for the original "two inodes" problem)?
- create a table to convert the uppderdir (real) inode number into the
  overlayfs (virtual) inode number.
- using the table, you can get the virtual inum from the real inum.
- as long as you have a single real inum (for hardlinks), you will get a
  single virtual inum.


J. R. Okajima

Re: Question about overlayfs ovl_link

[Miklos Szeredi]

Robin Dong <hao.bigrat@gmail.com> writes:

> 在 2012年2月28日 下午4:41，Miklos Szeredi <miklos@szeredi.hu> 写道：
> We have backported the overlayfs to our kernel (2.6.32) and find out
> that when making hard link for a upper file, the kernel will BUG_ON,
> the reason is:
>
> After "ln hello bye" (as the example above and imaging file "hello" is
> an executive program), there are two overlayfs dentries
> point to just one inode. Then we run "./hello", the d_count of "hello"
> dentry become 1 (by __d_lookup), and ovl_permission will try to get
> the alias
> dentry of this inode:
>
>                 alias = list_entry(inode->i_dentry.next,
>                                    struct dentry, d_alias);
>                 dget(alias);
>
> but it will find out "bye" dentry and its d_count is zero (because we
> get the inode from another dentry--"hello").
> It will report BUG_ON when trying to dget a zero d_count dentry in
> 2.6.32 kernel:
>
> static inline struct dentry *dget(struct dentry *dentry)
> {
>         if (dentry) {
>                 BUG_ON(!atomic_read(&dentry->d_count));
>                 atomic_inc(&dentry->d_count);
>         }
>         return dentry;
> }
>
> There are two ways to fix this problem.
> First, traverse all alias of inode to find a non-zero-d_count dentry,
> this may be inefficient
> Second, create a new overlayfs inode and a new overlayfs dentry in
> ovl_link, that will make the result of two actions
> ("create link" then "mount", or "mount" then "create link")
> consistent.

Okay, I understand the problem now.

Creating a new inode in ovl_link might be the better solution here, I
think.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html