From: Pavel Emelyanov <xemul@virtuozzo.com>
To: Amir Goldstein <amir73il@gmail.com>, Miklos Szeredi <miklos@szeredi.hu>
Cc: Jan Kara <jack@suse.com>, Al Viro <viro@zeniv.linux.org.uk>,
linux-unionfs@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/2] ovl: support freeze/thaw super
Date: Mon, 23 Jan 2017 16:23:35 +0300 [thread overview]
Message-ID: <588603D7.4060500@virtuozzo.com> (raw)
In-Reply-To: <CAOQ4uxg-i0SMXRTDdPS2GxWKUYDKAu30wT9bjXX1Gd2CzeJ2Yg@mail.gmail.com>
On 01/23/2017 11:47 AM, Amir Goldstein wrote:
> On Thu, Jan 19, 2017 at 2:13 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> freeze/thaw of upper is all that is needed.
>>
>
> Miklos,
>
> Looking at it again, I believe that not even that is needed.
> Having fixed ovl_sync_fs() with patch #2, ovl_freeze()
> and ovl_unfreeze() need to be NOP. Am I right?
>
> In fact, freezing upper fs, when many overlayfs mounts
> share the same base fs (a-la docker) would be quite lame.
>
> WRT other use cases of freezing overlayfs, I am not sure
> if it is needed for correctness of docker checkpoint/restart?
>
> Pavel?
Thanks for the heads-up :)
Good question. Actually we haven't yet experimented with doing _full_
(with FS) snapshot of containers, but at the first glance I can't
see the need for OVL freeze :( We stop all the processes in entry.S
effectively, so no in-flight IO can be happening.
>> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
>> ---
>> fs/overlayfs/super.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 6792bb7..0f8a9c8 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -160,6 +160,20 @@ static void ovl_put_super(struct super_block *sb)
>> kfree(ufs);
>> }
>>
>> +static int ovl_freeze(struct super_block *sb)
>> +{
>> + struct ovl_fs *ufs = sb->s_fs_info;
>> +
>> + return ufs->upper_mnt ? freeze_super(ufs->upper_mnt->mnt_sb) : 0;
>> +}
>> +
>> +static int ovl_unfreeze(struct super_block *sb)
>> +{
>> + struct ovl_fs *ufs = sb->s_fs_info;
>> +
>> + return ufs->upper_mnt ? thaw_super(ufs->upper_mnt->mnt_sb) : 0;
>> +}
>> +
>> /**
>> * ovl_statfs
>> * @sb: The overlayfs super block
>> @@ -222,6 +236,8 @@ static int ovl_remount(struct super_block *sb, int *flags, char *data)
>>
>> static const struct super_operations ovl_super_operations = {
>> .put_super = ovl_put_super,
>> + .freeze_fs = ovl_freeze,
>> + .unfreeze_fs = ovl_unfreeze,
>> .statfs = ovl_statfs,
>> .show_options = ovl_show_options,
>> .remount_fs = ovl_remount,
>> --
>> 2.7.4
>>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@virtuozzo.com>
To: Amir Goldstein <amir73il@gmail.com>, Miklos Szeredi <miklos@szeredi.hu>
Cc: Jan Kara <jack@suse.com>, Al Viro <viro@zeniv.linux.org.uk>,
<linux-unionfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/2] ovl: support freeze/thaw super
Date: Mon, 23 Jan 2017 16:23:35 +0300 [thread overview]
Message-ID: <588603D7.4060500@virtuozzo.com> (raw)
In-Reply-To: <CAOQ4uxg-i0SMXRTDdPS2GxWKUYDKAu30wT9bjXX1Gd2CzeJ2Yg@mail.gmail.com>
On 01/23/2017 11:47 AM, Amir Goldstein wrote:
> On Thu, Jan 19, 2017 at 2:13 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> freeze/thaw of upper is all that is needed.
>>
>
> Miklos,
>
> Looking at it again, I believe that not even that is needed.
> Having fixed ovl_sync_fs() with patch #2, ovl_freeze()
> and ovl_unfreeze() need to be NOP. Am I right?
>
> In fact, freezing upper fs, when many overlayfs mounts
> share the same base fs (a-la docker) would be quite lame.
>
> WRT other use cases of freezing overlayfs, I am not sure
> if it is needed for correctness of docker checkpoint/restart?
>
> Pavel?
Thanks for the heads-up :)
Good question. Actually we haven't yet experimented with doing _full_
(with FS) snapshot of containers, but at the first glance I can't
see the need for OVL freeze :( We stop all the processes in entry.S
effectively, so no in-flight IO can be happening.
>> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
>> ---
>> fs/overlayfs/super.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 6792bb7..0f8a9c8 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -160,6 +160,20 @@ static void ovl_put_super(struct super_block *sb)
>> kfree(ufs);
>> }
>>
>> +static int ovl_freeze(struct super_block *sb)
>> +{
>> + struct ovl_fs *ufs = sb->s_fs_info;
>> +
>> + return ufs->upper_mnt ? freeze_super(ufs->upper_mnt->mnt_sb) : 0;
>> +}
>> +
>> +static int ovl_unfreeze(struct super_block *sb)
>> +{
>> + struct ovl_fs *ufs = sb->s_fs_info;
>> +
>> + return ufs->upper_mnt ? thaw_super(ufs->upper_mnt->mnt_sb) : 0;
>> +}
>> +
>> /**
>> * ovl_statfs
>> * @sb: The overlayfs super block
>> @@ -222,6 +236,8 @@ static int ovl_remount(struct super_block *sb, int *flags, char *data)
>>
>> static const struct super_operations ovl_super_operations = {
>> .put_super = ovl_put_super,
>> + .freeze_fs = ovl_freeze,
>> + .unfreeze_fs = ovl_unfreeze,
>> .statfs = ovl_statfs,
>> .show_options = ovl_show_options,
>> .remount_fs = ovl_remount,
>> --
>> 2.7.4
>>
> .
>
next prev parent reply other threads:[~2017-01-23 13:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 12:13 [PATCH 0/2] overlayfs: support freeze/thaw/syncfs Amir Goldstein
2017-01-19 12:13 ` [PATCH 1/2] ovl: support freeze/thaw super Amir Goldstein
2017-01-23 8:47 ` Amir Goldstein
2017-01-23 13:23 ` Pavel Emelyanov [this message]
2017-01-23 13:23 ` Pavel Emelyanov
2017-04-03 11:27 ` Amir Goldstein
2017-04-04 17:47 ` Serge E. Hallyn
2017-04-04 18:01 ` Tycho Andersen
2017-04-04 18:59 ` Amir Goldstein
2017-04-04 19:07 ` Tycho Andersen
2017-01-19 12:13 ` [PATCH 2/2] ovl: properly implement sync_filesystem() Amir Goldstein
2017-01-24 17:14 ` Christoph Hellwig
2017-01-25 17:51 ` Amir Goldstein
2017-01-19 19:03 ` [PATCH 0/2] overlayfs: support freeze/thaw/syncfs Amir Goldstein
2017-01-20 8:27 ` Jan Kara
2017-01-20 8:41 ` Amir Goldstein
2017-01-20 8:49 ` Amir Goldstein
2017-01-20 12:03 ` Eryu Guan
2017-01-20 8:50 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=588603D7.4060500@virtuozzo.com \
--to=xemul@virtuozzo.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.