SELinux on XFS filesystems
I’ve been a huge fan of XFS for many, many years. Its quick, its efficient, and it works very well. Times have changed however since the first time I used XFS. There seem to be a lot of misinformation on the web of using selinux with XFS - mainly about the size of the required inodes.
A bit of history
Ok, so in a filesystem you have these things called inodes.
Inodes basically store information about files and folders, such as (user and group) ownership, access mode (read, write, execute permissions) and file type - Wikipedia.
SELinux stores an extended attribute in the security namespace as part of the inode. Now the key part - if the inode is not big enough to fit its usual data and the extra selinux data in, then a block from the filesystem is used to store the extra data. This usually means that the system will use 4Kb of space for around 50-60 bytes of additional data.
This is a problem. Not only because we waste 90% of the 4kb, but for performance as well as for every read to this inode will also require a read of the 4Kb block associated with the inode - wherever that may be on the filesystem.
The misinformation
Many sites around the web say that it is better to use a 512 byte inode. This will just about guarantee that all information required is in the one inode. This used to hold true - however these days, XFS uses a different method to write these inodes.
This means that the data for 99.9% of files will fit within a 256 byte inode - and it may even increase performance to do this. The change can be seen in Eric Sandeen’s post to a bugzilla report regarding this subject.
This is summerised as such:
Ondisk format extension for extended attributes (attr2)
Basically, the data/attr forks now grow up/down from either end of the literal area, rather than dividing the literal area into two chunks and growing both upward. Means we can now make much more efficient use of the attribute space, incl. fitting DMF attributes inline in 256 byte inodes, and large jumps in dbench3 performance numbers. It is self enabling, but can be forced on/off via the attr2/noattr2 mount options.
So what does this mean? In short, if you are using XFS and SELinux together, you should do perfectly well with the defaults of your XFS creation by the OS installer. Running xfs_info /dev/sdaX
on your system will allow you to check the size of your inodes (isize) and if attrs=2 has been set on your filesystem creation. You should see something like:
1
2
3
4
5
6
7
8
meta-data=/dev/sda3 <strong>isize=256</strong> agcount=4, agsize=15112064 blks
= sectsz=512 <strong>attr=2</strong>
data = bsize=4096 blocks=60448256, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=29515, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
If you do, all is well. If not, lodge a bug with your distro!
Oh, and if you want to check your existing XFS partition for out of inode data, run the following:
1
for FILE in `find / -xdev`; do xfs_bmap -a $FILE; done | grep -v "no extents"
This will list all files that have an extra block allocated for extended attributes.
Comments powered by Disqus.