From: Jan Kara <jack@suse.cz>
To: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Cc: Jan Kara <jack@suse.cz>,
djwong@kernel.org, Luis Chamberlain <mcgrof@kernel.org>,
linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-xfs@vger.kernel.org, linux-mm@kvack.org,
dan.j.williams@intel.com, willy@infradead.org,
akpm@linux-foundation.org
Subject: Re: [RFC PATCH v11.1 2/2] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind
Date: Tue, 25 Apr 2023 15:23:15 +0200 [thread overview]
Message-ID: <20230425132315.u5ocvbneeqzzbifl@quack3> (raw)
In-Reply-To: <d557c0cb-e244-6238-2df4-01ce75ededdf@fujitsu.com>
On Tue 25-04-23 20:47:35, Shiyang Ruan wrote:
>
>
> 在 2023/4/20 20:09, Jan Kara 写道:
> > On Thu 20-04-23 10:07:39, Shiyang Ruan wrote:
> > > 在 2023/4/12 18:52, Shiyang Ruan 写道:
> > > > This is a RFC HOTFIX.
> > > >
> > > > This hotfix adds a exclusive forzen state to make sure any others won't
> > > > thaw the fs during xfs_dax_notify_failure():
> > > >
> > > > #define SB_FREEZE_EXCLUSIVE (SB_FREEZE_COMPLETE + 2)
> > > > Using +2 here is because Darrick's patch[0] is using +1. So, should we
> > > > make these definitions global?
> > > >
> > > > Another thing I can't make up my mind is: when another freezer has freeze
> > > > the fs, should we wait unitl it finish, or print a warning in dmesg and
> > > > return -EBUSY?
> > > >
> > > > Since there are at least 2 places needs exclusive forzen state, I think
> > > > we can refactor helper functions of freeze/thaw for them. e.g.
> > > > int freeze_super_exclusive(struct super_block *sb, int frozen);
> > > > int thaw_super_exclusive(struct super_block *sb, int frozen);
> > > >
> > > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=repair-fscounters&id=c3a0d1de4d54ffb565dbc7092dfe1fb851940669
> >
> > I'm OK with the idea of new freeze state that does not allow userspace to
> > thaw the filesystem. But I don't really like the guts of filesystem
> > freezing being replicated inside XFS. It is bad enough that they are
> > replicated in [0], replicating them *once more* in another XFS file shows
> > we are definitely doing something wrong. And Luis will need yet another
> > incantation of the exlusive freeze for suspend-to-disk. So please guys get
> > together and reorganize the generic freezing code so that it supports
> > exclusive freeze (for in-kernel users) and works for your usecases instead
> > of replicating it inside XFS...
>
> I agree that too much replicating code is not good. It's necessary to
> create a generic exclusive freeze/thaw for all users. But for me, I don't
> have the confidence to do it well, because it requires good design and code
> changes will involve other filesystems. It's diffcult.
>
> However, I hope to be able to make progress on this unbind feature. Thus, I
> tend to refactor a common helper function for xfs first, and update the code
> later when the generic freeze is done.
I think Darrick was thinking about working on a proper generic interface.
So please coordinate with him.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-04-25 13:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 9:41 [PATCH v11 0/2] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind Shiyang Ruan
2023-03-28 9:41 ` [PATCH v11 1/2] xfs: fix the calculation of length and end Shiyang Ruan
2023-03-28 9:41 ` [PATCH v11 2/2] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind Shiyang Ruan
2023-04-04 17:45 ` Darrick J. Wong
2023-04-05 1:28 ` Yasunori Gotou (Fujitsu)
2023-04-05 4:36 ` Dan Williams
2023-04-06 10:50 ` Shiyang Ruan
2023-04-06 14:54 ` Darrick J. Wong
2023-04-07 2:07 ` Shiyang Ruan
2023-04-12 10:52 ` [RFC PATCH v11.1 " Shiyang Ruan
2023-04-20 2:07 ` Shiyang Ruan
2023-04-20 12:09 ` Jan Kara
2023-04-25 12:47 ` Shiyang Ruan
2023-04-25 13:23 ` Jan Kara [this message]
2023-04-25 15:18 ` Darrick J. Wong
2023-04-26 2:27 ` Shiyang Ruan
2023-04-26 2:37 ` Darrick J. Wong
2023-04-04 4:33 ` [PATCH v11 0/2] " Shiyang Ruan
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=20230425132315.u5ocvbneeqzzbifl@quack3 \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=ruansy.fnst@fujitsu.com \
--cc=willy@infradead.org \
/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.