Steve's Blog

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.

Linux on the Desktop

It’s been almost an eternity since I’ve had Linux on any desktop. Fedora was known as RedHat Linux, Ubuntu didn’t exist, and Windows XP was the norm (and some argue it still is!). While I’ve always used the Redhat Enterprise Linux (RHEL) clone CentOS on server systems, I’ve strictly run Windows or OSX on all desktops.

Things changed recently when I got myself an Asus EeePC 1005P netbook. It’s quite a nice machine - but it just seems to thrash around a little under the shipped Windows 7 install. It doesn’t get any better replacing it with Windows 7 Ultimate either. I’d heard a lot about running Linux on netbooks on the various geek sites (slashdot.org etc) and I figured I’d give it a try.

With my RHEL background, I decided to go with Fedora 13. Installation was painless, it booted and just ran. With about half the memory footprint of Windows 7, the increase in speed was quite noticeable. A faster hard disk and things would be much nicer - especially if I swapped out the standard HDD for a solid state drive.

As far as compatibility goes I was more than impressed. The onboard wifi, bluetooth, ethernet, even display controller were detected and ran perfectly - right out of the box. Power management seems to be much better implemented. A few simple scripts later and I had the Super Hybrid Engine working correctly as well. Much, much better than my last attempt at linux on the desktop!

What impressed me even more is that I turned up to do a contracting gig and needed to print to the office printer. The first thing I thought was “oh no, here we go”. Imagine my surprise when I pointed Fedora to the printers IP address and away it went. No external drivers, no fuss. Even advanced features like duplex printing worked out of the box.

In summary, Fedora has come a long, long way since the RHL days and I’ve been using it every day for around 3 weeks now with no major issues at all. Keep up the good work!

Digital CoPilot is born

It’s been a long time since I started this project - nearly 8 months of solid work - however its starting to get close to completion and the Digital CoPilot web site is now up and running!

My aims for this device is to be simple, user friendly, and a very handy tool in the quest to make aviation safer for everyone.

As with everything I do, any feedback is welcome :)