From: Dave Chinner <david@fromorbit.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: dsterba@suse.cz, Liu Bo <bo.li.liu@oracle.com>,
linux-btrfs@vger.kernel.org, fdmanana@suse.com, kzak@redhat.com,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
linux-nfs@vger.kernel.org, chuck.lever@oracle.com,
mingming.cao@oracle.com
Subject: Re: i_version vs iversion (Was: Re: [RFC PATCH v2 1/2] Btrfs: add noi_version option to disable MS_I_VERSION)
Date: Thu, 25 Jun 2015 09:59:00 +1000 [thread overview]
Message-ID: <20150624235900.GC7943@dastard> (raw)
In-Reply-To: <20150624231750.GE14324@thunk.org>
On Wed, Jun 24, 2015 at 07:17:50PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 24, 2015 at 08:02:15PM +0200, David Sterba wrote:
> >
> > This sounds similar to what Dave proposed, a per-inode I_VERSION
> > attribute that can be changed through chattr. Though the negated meaning
> > of the flag could be confusing, I had to reread the paragraph again.
>
> Dave did not specify an I_VERSION attribute that would be stored on
> disk. Instead he talked about a inode flag that would be set when the
> struct inode is created by the file system.
Right.
> This would allow file systems to permanently configure (on a per-inode
> basis) whether or not a particular inode would require a forced
> i_version update any time the inode's data or metadata is modified. I
> suppose you could initialized the inode flag from an on-disk
> attribute, but that wasn't implied by Dave's proposal, at least as I
> understood it.
It enables filesystems to do this. If btrfs want to add an on-disk
flag to turn off I_VERSION on a per-inode basis, or imply it from
some other on-disk flag, then they are welcome to do so and the
above infrastructure change will support it.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
To: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Cc: dsterba-AlSwsSmVLrQ@public.gmane.org,
Liu Bo <bo.li.liu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
fdmanana-IBi9RG/b67k@public.gmane.org,
kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
mingming.cao-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
Subject: Re: i_version vs iversion (Was: Re: [RFC PATCH v2 1/2] Btrfs: add noi_version option to disable MS_I_VERSION)
Date: Thu, 25 Jun 2015 09:59:00 +1000 [thread overview]
Message-ID: <20150624235900.GC7943@dastard> (raw)
In-Reply-To: <20150624231750.GE14324-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
On Wed, Jun 24, 2015 at 07:17:50PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 24, 2015 at 08:02:15PM +0200, David Sterba wrote:
> >
> > This sounds similar to what Dave proposed, a per-inode I_VERSION
> > attribute that can be changed through chattr. Though the negated meaning
> > of the flag could be confusing, I had to reread the paragraph again.
>
> Dave did not specify an I_VERSION attribute that would be stored on
> disk. Instead he talked about a inode flag that would be set when the
> struct inode is created by the file system.
Right.
> This would allow file systems to permanently configure (on a per-inode
> basis) whether or not a particular inode would require a forced
> i_version update any time the inode's data or metadata is modified. I
> suppose you could initialized the inode flag from an on-disk
> attribute, but that wasn't implied by Dave's proposal, at least as I
> understood it.
It enables filesystems to do this. If btrfs want to add an on-disk
flag to turn off I_VERSION on a per-inode basis, or imply it from
some other on-disk flag, then they are welcome to do so and the
above infrastructure change will support it.
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-06-24 23:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 7:54 [RFC PATCH v2 1/2] Btrfs: add noi_version option to disable MS_I_VERSION Liu Bo
2015-06-17 7:54 ` [RFC PATCH v2 2/2] Btrfs: improve fsync for nocow file Liu Bo
2015-06-17 15:58 ` David Sterba
2015-06-18 3:27 ` Liu Bo
2015-06-24 18:21 ` David Sterba
2015-06-25 2:24 ` Liu Bo
2015-06-25 16:10 ` David Sterba
2015-06-17 15:33 ` [RFC PATCH v2 1/2] Btrfs: add noi_version option to disable MS_I_VERSION David Sterba
2015-06-17 15:52 ` Liu Bo
2015-06-17 17:01 ` David Sterba
2015-06-18 2:46 ` Liu Bo
2015-06-18 14:38 ` i_version vs iversion (Was: Re: [RFC PATCH v2 1/2] Btrfs: add noi_version option to disable MS_I_VERSION) David Sterba
2015-06-19 11:44 ` Karel Zak
2015-06-19 11:44 ` Karel Zak
2015-06-22 20:42 ` Dave Chinner
2015-06-22 20:42 ` Dave Chinner
2015-06-24 17:28 ` David Sterba
2015-06-23 16:32 ` Theodore Ts'o
2015-06-24 8:23 ` Liu Bo
2015-06-24 18:02 ` David Sterba
2015-06-24 23:17 ` Theodore Ts'o
2015-06-24 23:17 ` Theodore Ts'o
2015-06-24 23:59 ` Dave Chinner [this message]
2015-06-24 23:59 ` Dave Chinner
2015-06-25 18:46 ` J. Bruce Fields
2015-06-25 18:46 ` J. Bruce Fields
2015-06-25 22:12 ` Theodore Ts'o
2015-06-26 13:32 ` J. Bruce Fields
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=20150624235900.GC7943@dastard \
--to=david@fromorbit.com \
--cc=bo.li.liu@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@suse.com \
--cc=kzak@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mingming.cao@oracle.com \
--cc=tytso@mit.edu \
--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.