On 9/11/13 6:30 AM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 10:13:16PM -0500, Eric Sandeen wrote:
>>
>> Above doesn't tell us the prevalence of various contexts on the actual system,
>> but they are all under 100 bytes in any case.
>
> OK, so in other words, on your system i_file_acl and i_file_acl_high
> (which is where we store the block # for the external xattr block),
> should always be zero for all inodes, yes?
Oh, hum - ok, so that would have been the better thing to check (or at
least an additional thing).
# find / -xdev -exec filefrag -x {} \; | awk -F : '{print $NF}' | sort | uniq -c
Finds quite a lot that claim to have external blocks, but it seems broken:
# filefrag -xv /var/lib/yum/repos/x86_64/6Server/epel
Filesystem type is: ef53
File size of /var/lib/yum/repos/x86_64/6Server/epel is 4096 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 32212996252 100 not_aligned,inline
/var/lib/yum/repos/x86_64/6Server/epel: 1 extent found
So _filefrag_ says it has a block (at a 120T physical address not on my fs!)
And yet it's a small attr:
# getfattr -m - -d /var/lib/yum/repos/x86_64/6Server/epel
getfattr: Removing leading '/' from absolute path names
# file: var/lib/yum/repos/x86_64/6Server/epel
security.selinux="unconfined_u:object_r:rpm_var_lib_t:s0"
And debugfs thinks it's stored within the inode:
debugfs: stat var/lib/yum/repos/x86_64/6Server/epel
Inode: 1968466 Type: directory Mode: 0755 Flags: 0x80000
Generation: 2728788146 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 2 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x50b4d808:cb7dd9a8 -- Tue Nov 27 09:11:04 2012
atime: 0x522fc8fa:62eb2d90 -- Tue Sep 10 20:35:54 2013
mtime: 0x50b4d808:cb7dd9a8 -- Tue Nov 27 09:11:04 2012
crtime: 0x50b4d808:cb7dd9a8 -- Tue Nov 27 09:11:04 2012
Size of extra inode fields: 28
Extended attributes stored in inode body:
selinux = "unconfined_u:object_r:rpm_var_lib_t:s0\000" (39)
EXTENTS:
(0): 7873422
sooo seems like filefrag -x is buggy and can't be trusted. :(
> Thavatchai, can you check to see whether or not this is true on your
> system? You can use debugfs on the file system, and then use the
> "stat" command to sample various inodes in your system. Or I can make
> a version of e2fsck which counts the number of inodes with external
> xattr blocks --- it sounds like this is something we should do anyway.
>
> One difference might be that Eric ran this test on RHEL 6, and
> Thavatchai is using an upstream kernel, so maybe this is bloat has
> been added recently?
It's a userspace policy so the kernel shouldn't matter... "bloat" would
only come from new, longer contexts (outside the kernel).
> The reason why I'm pushing here is that mbcache shouldn't be showing
> up in the profiles at all if there is no external xattr block. And so
> if newer versions of SELinux (like Adnreas, I've been burned by
> SELinux too many times in the past, so I don't use SELinux on any of
> my systems) is somehow causing mbcache to get triggered, we should
> figure this out and understand what's really going on.
selinux, from an fs allocation behavior perspective, is simply setxattr.
And as I showed earlier, name+value for all of the attrs set by at least RHEL6
selinux policy are well under 100 bytes.
(Add in a bunch of other non-selinux xattrs, and you'll go out of a 256b inode,
sure, but selinux on its own should not).
> Sigh, I suppose I should figure out how to create a minimal KVM setup
> which uses SELinux just so I can see what the heck is going on....
http://fedoraproject.org/en/get-fedora ;)
-Eric
> - Ted
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
