All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Adrian Bunk <bunk@kernel.org>,
	Andreas Gruenbacher <agruen@suse.de>,
	linux-ext4@vger.kernel.org
Subject: Re: [2.6 patch] FS_MBCACHE: don't needlessly make it built-in
Date: Sun, 17 Aug 2008 22:20:05 -0500	[thread overview]
Message-ID: <48A8EA65.9090204@redhat.com> (raw)
In-Reply-To: <20080817190431.GG4199@webber.adilger.int>

Andreas Dilger wrote:
> On Aug 03, 2008  21:43 +0300, Adrian Bunk wrote:
>> Assume you have:
>> - one or more of ext2/3/4 statically built into your kernel
>> - none of these with extended attributes enabled and
>> - want to add onother one of ext2/3/4 modular and with
>>   extended attributes enabled
>>
>> then you currently have to reboot to use it since this results in 
>> CONFIG_FS_MBCACHE=y.
>>
>> That's not a common issue, but I just ran into it and since there's no 
>> reason to get a built-in mbcache in this case this patch fixes it.
> 
> To be honest, I'd like an option to disable MBCACHE entirely.  This
> code is of no use if the EAs on an inode are not identical (i.e. if
> anything other than ACLs are in use)

or selinux....

> and is also not useful if the
> xattrs fit into the large inodes in ext4 (and ext3 if the filesystem
> is formatted with this option).

... which is now the default.

a config option sounds reasonable to me, too.  I think by the time EAs
spill out of the inode, the chance of them being identical is pretty
small?  (i.e. a single acl set, or selinux context may be common, but if
you have enough to not fit in the inode it's more likely to be a
mishmash of things?)

-Eric


> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.


      reply	other threads:[~2008-08-18  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-03 18:43 [2.6 patch] FS_MBCACHE: don't needlessly make it built-in Adrian Bunk
2008-08-17 19:04 ` Andreas Dilger
2008-08-18  3:20   ` Eric Sandeen [this message]

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=48A8EA65.9090204@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@sun.com \
    --cc=agruen@suse.de \
    --cc=bunk@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 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.