From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Christoph Hellwig <hch@lst.de>, Theodore Ts'o <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Mark Fasheh <mfasheh@versity.com>,
linux-xfs@vger.kernel.org, linux-unionfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/5] VFS API for getting filesystem's UUID
Date: Sun, 30 Apr 2017 01:54:58 +0100 [thread overview]
Message-ID: <20170430005455.GV29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170429230159.GM12369@dastard>
On Sun, Apr 30, 2017 at 09:01:59AM +1000, Dave Chinner wrote:
> Doesn't this make the struct export_opierations .get_uuid method
> somewhat redundant? Shouldn't that now be replaced with generic
> functions that looks at SB_I_HAVE_UUID before allowing PNFS export
> is allowed and then just use s_uuid directly in the PNFS code?
Do we even need a flag? Checking if 16 bytes are not all zeroes isn't hard,
after all...
next prev parent reply other threads:[~2017-04-30 0:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 8:59 [PATCH 0/5] VFS API for getting filesystem's UUID Amir Goldstein
2017-04-27 8:59 ` [PATCH 1/5] vfs: define a flag to indicate sb->s_uuid is available Amir Goldstein
2017-04-27 19:34 ` Darrick J. Wong
2017-04-27 8:59 ` [PATCH 2/5] ext4: set the super block SB_I_HAVE_UUID flag Amir Goldstein
2017-04-27 8:59 ` [PATCH 3/5] f2fs: " Amir Goldstein
2017-04-27 8:59 ` [PATCH 4/5] ocfs2: " Amir Goldstein
2017-04-27 8:59 ` [PATCH 5/5] xfs: " Amir Goldstein
2017-04-27 9:09 ` [PATCH 0/5] VFS API for getting filesystem's UUID Miklos Szeredi
2017-04-29 23:01 ` Dave Chinner
2017-04-30 0:54 ` Al Viro [this message]
2017-04-30 5:04 ` Amir Goldstein
2017-04-30 5:01 ` Amir Goldstein
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=20170430005455.GV29622@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=amir73il@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mfasheh@versity.com \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
/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.