[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50BFF5D6.7050804@tao.ma>
Date: Thu, 06 Dec 2012 09:33:10 +0800
From: Tao Ma <tm@....ma>
To: Theodore Ts'o <tytso@....edu>
CC: linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: RFC: remove CONFIG_EXT4_FS_XATTR
On 12/06/2012 06:35 AM, Theodore Ts'o wrote:
>
> The number of build warnings that were generated with the inline data
> patch makes me think that perhaps we should just remove
> CONFIG_EXT4_FS_XATTR. Turning off CONFIG_EXT4_FS_XATTR causes a net
> decrease in the ext4 file system by 27k (about 7.3% if ext4 is built as
> a module; the entire compiled kernel's text+data size for my
> all-in-one-no-modules-for-kvm-testing is 19 megabytes).
>
> Another advantage of making this change is with the inline data option,
> if you turn off CONFIG_EXT4_FS_XATTR, it will still allow a file system
> with inline_data to be mounted, but then attempts to read small files or
> small directories will end up returning EOPNOTSUPP, which will be
> surprising to end users in a very serious way. (Assuming it works at
> all; I haven't tested to make sure it fails cleanly, and I'm not sure
> Tao has tested that case either; so easing our test matrix is another
> reason why removing this config option would be helpful.)
To be frank, I didn't try the inline data test without xattr support. So
that would be great if we remove it. :)
btw, does any distribution disable xattr support during kernel build? As
Eric said on behalf of redhat, and in my ubuntu box xattr is enabled.
Would Jan confirm that SUSE also use it by default?
Thanks
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists