linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: 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: [RFC][PATCH v2 0/3] overlayfs: support freeze/thaw/syncfs
Date: Mon, 23 Jan 2017 21:52:22 +0200	[thread overview]
Message-ID: <CAOQ4uxgWYX-AbUW53XW1vx6-2ZA3PKBxfk0bSBaAKoPfBdiF-w@mail.gmail.com> (raw)
In-Reply-To: <1485174742-15866-1-git-send-email-amir73il@gmail.com>

On Mon, Jan 23, 2017 at 2:32 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> Miklos,
>
> Take #2 for overlayfs freeze.
>
> Patch #2 I am quite confident is a bug fix and I have written an
> xfs specific test for it.
>
> Patch #1 is a POC of what I think overlay freezing should be like,
> although we may want to optimize it with some file flag?
>
> Patch #3 just enables overlayfs freezing with NOP freeze_fs()
> unfreeze_fs() operations, so I could test it.  It behaves as
> expected - overlay and underlying fs can be frozen independently
> and writes continue when both fs are thawed.
>
> I believe that mmap freeze protection is not covered, although I am
> not sure exactly how it works?
>
> Am I missing anything else?

Found a few missed spots ({copy,clone,dedup}_file_range() and
fallocate(). sent patch #4.

Anyway, I totally understand if the reaction to this patch set is
"what is the justification for overlayfs freeze", because outside
my use case I haven't found any yet.

I would still appreciate if you could tell me whether I am in the
general right direction, as I do need to carry these patches for
overlayfs snapshots.

As for patch #2, I am not sure how often apps use syncfs(2),
and whether or not any of the containers that use overlayfs relay
on it in some way, but it looks to me like something worth fixing.

Thanks,
Amir.

      parent reply	other threads:[~2017-01-23 19:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23 12:32 [RFC][PATCH v2 0/3] overlayfs: support freeze/thaw/syncfs Amir Goldstein
2017-01-23 12:32 ` [RFC][PATCH v2 1/3] vfs: freeze protect overlay inode on file_start_write() Amir Goldstein
2017-01-23 19:43   ` [RFC][PATCH v2 4/4] vfs: wrap write f_ops with file_{start,end}_write() Amir Goldstein
2017-01-24 10:09     ` Jan Kara
2017-01-27 11:09     ` Miklos Szeredi
2017-01-27 11:50       ` Amir Goldstein
2017-01-27 16:20         ` Amir Goldstein
2017-01-27 16:31           ` Darrick J. Wong
2017-01-27 17:29           ` Amir Goldstein
2017-01-27 17:51             ` Christoph Hellwig
2017-01-27 19:30           ` Michael Kerrisk (man-pages)
2017-01-27 20:09             ` Amir Goldstein
2017-01-31  7:11       ` Amir Goldstein
2017-02-06 14:49         ` Amir Goldstein
2017-02-07 15:03           ` Miklos Szeredi
2017-01-23 12:32 ` [RFC][PATCH v2 2/3] ovl: properly implement sync_filesystem() Amir Goldstein
2017-01-23 12:32 ` [RFC][PATCH v2 3/3] ovl: support freeze/thaw super Amir Goldstein
2017-01-23 19:52 ` Amir Goldstein [this message]

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=CAOQ4uxgWYX-AbUW53XW1vx6-2ZA3PKBxfk0bSBaAKoPfBdiF-w@mail.gmail.com \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).