public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jeff Layton <jlayton@kernel.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	dhowells@redhat.com
Subject: Re: [RFC PATCH] ext4: don't split xattr inode refcounts across i_ctime and i_version fields
Date: Thu, 11 Jan 2018 13:39:14 -0500	[thread overview]
Message-ID: <20180111183914.GE19241@thunk.org> (raw)
In-Reply-To: <1515524731.3571.16.camel@kernel.org>

On Tue, Jan 09, 2018 at 02:05:31PM -0500, Jeff Layton wrote:
>
> Ahh, many thanks...
> 
> My main question was: why split the refcount across fields like this? If
> it's necessary now for backward compatibility then so be it, but it's
> weird and not 100% clear why it's being done that way.

The main reason is that the only inode that will need it is the hidden
extended attribute inode (and then only for Samba servers that are
supporting enterprise domain CIFS servers where there are more than
64k files using the same windows ACL).  So we didn't want to use extra
bytes in the inode, since it's only going to be used in a very tiny
fraction of servers.

For the right workload, though, this should allow ext4 to have
significantly better performance, since if you are serving a large
directory where all of the files have their own ACL or Windows
security ID xattrs, without shared extended attributes, when you open
a Files explorer on that directory, for each file the file system will
be forced to do lots of random 4k reads to fetch the xattrs.

   	     	     	       	  	- Ted

  reply	other threads:[~2018-01-11 18:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 14:47 [RFC PATCH] ext4: don't split xattr inode refcounts across i_ctime and i_version fields Jeff Layton
2018-01-09 18:52 ` Darrick J. Wong
2018-01-09 19:05   ` Jeff Layton
2018-01-11 18:39     ` Theodore Ts'o [this message]
2018-01-11 20:09       ` Jeff Layton
2018-01-11 22:41         ` Theodore Ts'o

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=20180111183914.GE19241@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-ext4@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox