From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: david@fromorbit.com, viro@ZenIV.linux.org.uk,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
xfs@oss.sgi.com, linux-api@vger.kernel.org
Subject: Re: [PATCH 3/6] vfs: support FS_XFLAG_REFLINK and FS_XFLAG_COWEXTSIZE
Date: Mon, 12 Sep 2016 12:12:51 -0700 [thread overview]
Message-ID: <20160912191251.GB23422@birch.djwong.org> (raw)
In-Reply-To: <20160911125808.GD1399@infradead.org>
On Sun, Sep 11, 2016 at 05:58:08AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 06, 2016 at 12:15:15PM -0700, Darrick J. Wong wrote:
> > So far I've put the reflink flag to use in xfs_scrub to look for
> > obvious signs of brokenness such as extents that overlap or have the
> > shared flag set but the inode flag is off; and to skip various kinds
> > of checks that don't have to happen when blocks don't overlap.
> >
> > I doubt there's much of a use for the flag outside of the XFS utilities.
> > For a while I pondered only exposing the fsxattr flag if the caller had
> > CAP_SYS_ADMIN (the level of priviledge required to run scrub) but
> > decided that I wouldn't change the existing interface like that unless
> > I had a really good reason.
>
> I don't think CAP_SYS_ADMIN is nessecarily the right thing, but it's
> still an XFS implementation detail which I don't think we should
> pollute a flags API for normal user space applications with.
I can work around it in xfs_scrub, so I'll give back the xflag bit for
reflink.
--D
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-api@vger.kernel.org, xfs@oss.sgi.com,
linux-xfs@vger.kernel.org, viro@ZenIV.linux.org.uk,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/6] vfs: support FS_XFLAG_REFLINK and FS_XFLAG_COWEXTSIZE
Date: Mon, 12 Sep 2016 12:12:51 -0700 [thread overview]
Message-ID: <20160912191251.GB23422@birch.djwong.org> (raw)
In-Reply-To: <20160911125808.GD1399@infradead.org>
On Sun, Sep 11, 2016 at 05:58:08AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 06, 2016 at 12:15:15PM -0700, Darrick J. Wong wrote:
> > So far I've put the reflink flag to use in xfs_scrub to look for
> > obvious signs of brokenness such as extents that overlap or have the
> > shared flag set but the inode flag is off; and to skip various kinds
> > of checks that don't have to happen when blocks don't overlap.
> >
> > I doubt there's much of a use for the flag outside of the XFS utilities.
> > For a while I pondered only exposing the fsxattr flag if the caller had
> > CAP_SYS_ADMIN (the level of priviledge required to run scrub) but
> > decided that I wouldn't change the existing interface like that unless
> > I had a really good reason.
>
> I don't think CAP_SYS_ADMIN is nessecarily the right thing, but it's
> still an XFS implementation detail which I don't think we should
> pollute a flags API for normal user space applications with.
I can work around it in xfs_scrub, so I'll give back the xflag bit for
reflink.
--D
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-09-12 19:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 23:30 [PATCH v8 0/6] vfs: help support reflink for XFS Darrick J. Wong
2016-08-25 23:30 ` Darrick J. Wong
2016-08-25 23:30 ` [PATCH 1/6] vfs: fix return type of ioctl_file_dedupe_range Darrick J. Wong
2016-08-25 23:30 ` Darrick J. Wong
2016-08-25 23:30 ` [PATCH 2/6] vfs: cap dedupe request structure size at PAGE_SIZE Darrick J. Wong
2016-08-25 23:30 ` Darrick J. Wong
2016-09-05 14:55 ` Christoph Hellwig
2016-09-05 14:55 ` Christoph Hellwig
2016-09-05 14:55 ` Christoph Hellwig
2016-09-13 1:16 ` Darrick J. Wong
2016-09-13 1:16 ` Darrick J. Wong
2016-09-13 1:16 ` Darrick J. Wong
2016-09-14 20:22 ` Christoph Hellwig
2016-08-25 23:31 ` [PATCH 3/6] vfs: support FS_XFLAG_REFLINK and FS_XFLAG_COWEXTSIZE Darrick J. Wong
2016-08-25 23:31 ` Darrick J. Wong
2016-09-05 14:56 ` Christoph Hellwig
2016-09-05 14:56 ` Christoph Hellwig
2016-09-05 14:56 ` Christoph Hellwig
2016-09-06 19:15 ` Darrick J. Wong
2016-09-06 19:15 ` Darrick J. Wong
2016-09-06 19:15 ` Darrick J. Wong
2016-09-11 12:58 ` Christoph Hellwig
2016-09-12 19:12 ` Darrick J. Wong [this message]
2016-09-12 19:12 ` Darrick J. Wong
2016-08-25 23:31 ` [PATCH 4/6] fs: add iomap_file_dirty Christoph Hellwig
2016-08-25 23:31 ` Christoph Hellwig
2016-09-05 14:57 ` Christoph Hellwig
2016-09-05 14:57 ` Christoph Hellwig
2016-09-06 17:34 ` Darrick J. Wong
2016-09-06 17:34 ` Darrick J. Wong
2016-09-11 12:58 ` Christoph Hellwig
2016-09-19 0:11 ` Dave Chinner
2016-09-19 0:11 ` Dave Chinner
2016-08-25 23:31 ` [PATCH 5/6] iomap: don't set FIEMAP_EXTENT_MERGED for extent based filesystems Darrick J. Wong
2016-08-25 23:31 ` Darrick J. Wong
2016-08-25 23:31 ` [PATCH 6/6] iomap: add a flag to report shared extents Darrick J. Wong
2016-08-25 23:31 ` Darrick J. Wong
2016-08-25 23:31 ` Darrick J. Wong
2016-09-05 14:58 ` Christoph Hellwig
2016-09-05 14:58 ` Christoph Hellwig
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=20160912191251.GB23422@birch.djwong.org \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=xfs@oss.sgi.com \
/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.