Linux on XFS

 

Overview

This should just be a quick summary of a couple things I ran across when I was setting up an XFS / filesystem on Linux with a 2.4.5 kernel - using a basic 'backup' approach. For example... RedHat 7.1 has an XFS-capable install CD/floppy? that will let you install on an XFS filesystem to begin with... but I don't see much fun (or learning ;-) in that method.

SGI has pretty decent documentation at or around http://oss.sgi.com/projects/xfs for XFS on Linux... if you have a fair idea what they are talking about - but some of the tips might seem vague if you want more of a 'hand-holding' approach.

A Linux + XFS HOWTO is up at http://www.gargoylecc.com/Linux+XFS-HOWTO.html - nice complement to the SGI documentation.

My only real addition to the existing documentation at the two sites above concerns an (obvious?) /boot tip when migrating your old filesystems to XFS. I always use a small /boot partition - which needs to be left as 'ext2' in the XFS migration, but you will want to temporarily mount the /boot partition below your new XFS / before you run LILO (more about this later)

I might take a look at using LVM (http://www.sistina.com/lvm/) with XFS later - especially practical if you have to work with making/growing filesystems on a running system.

I had a rather unpleasant experience with a dual-boot Windows/Linux installation... when I recreated/formatted a fat32 partition that I had used for a 'temporary' partition for the filesystem migration. In a nutshell... I had booted to Linux without incident several times with the new XFS system - but formatting a fat32 logical drive from Windows seemed to hose the XFS filesystem and/or partition information. I'm thinking it was probably a bad idea to have the fat32 partition as a logical drive in the same extended partition that contained the XFS stuff.

I partitioned my next attempt with the following setup... and haven't had any problems -

For the extremely lazy (or lucky?) people - a spare hard-drive should reduce the likelihood for disasters in the filesystem migration. In general... non-destructive repartitioning is *possible* and helpful, but you'll probably have to look elsewhere for help - since I don't want to discuss the potential issues here ;-)

For the actual filesystem copying, I prefer the suggestion given at the SGI site -

This is the basic formula you need for copying your filesystems around for 'backups' or 'restores' in the XFS adventure.

find <source mountpoint> -mount -print | cpio -pdm <destination mountpoint>

The -mount option keeps the 'find' from crossing filesystems (partitions) - which is especially important if you happen to have multiple partitions (/, /usr, etc...)

 

Compiling an XFS-capable kernel

I prefer to grab 'original' kernel source (Linus' version) from www.kernel.org and just the corresponding XFS patch from SGI's site at ftp://oss.sgi.com/projects/xfs/download/

You'll also want to grab the various XFS utility programs in the cmd_tars directory for later (don't compile these yet)

I always do something like the following when I unzip/untar kernel source (in my home directory)

Then rename 'linux' accordingly (I'll call it linux-2.4.5-xfs since it's going to be patched with the XFS stuff)

To apply the XFS patch (linux-2.4.5-xfs-06112001.patch.bz2) to the kernel source...

A 1.0.1 stable? release was released right after I finished writing most of this - so you might want to grab some/all of the patches (XFS patches and some changes to the kernel code) SGI seems to be catering to Red Hat and/or rpm systems... but the source code for everything is at ftp://oss.sgi.com if you look around a bit.

Finally... you want to move the linux-2.4.5-xfs directory to /usr/src and adjust the 'linux' symlink to point at linux-2.4.5-xfs

As for building the kernel with XFS support - the most important changes are under 'Filesystems' (again... from a 'make menuconfig' perspective) You'll need to enable at least 'Page Buffer support' and 'SGI XFS filesystem support' - both built into the kernel itself (not modules... since that will just cause extra work later... and I don't see any reason for it)

Some linux distributions ship 'development' compilers with well-known problems (RedHat, Mandrake, ?) - and you want to avoid building your kernel with these compilers. I'm using Slackware 8.0 - which ships with gcc-2.95.3 and egcs-1.1.2 (2.91.66)... and it's probably a good idea to build the kernel with the egcs compiler.

A simple way to use 'egcs' is to just provide a 'CC' variable to the 'make dep', 'make bzImage', and 'make modules' commands -

(It's assumed that you can configure/build/install a new kernel from this point)

Add a section to your /etc/lilo.conf for your new kernel... run 'lilo' and reboot with the new kernel.

 

Install the XFS tools

Grab the XFS stuff from the SGI ftp site mentioned earlier... if you haven't already done so.

You'll want to build the utilities in the following order -

I'll never understand the reasoning behind splitting packages into 'blah' and 'blah-devel' (I guess they like RedHat?) - but if you look at the makefiles in the various XFS utilities... there are both 'install' and 'install-dev' rules... so you'll want to do something like the following -

This might go without saying... but before you start compiling the XFS utilities - make sure /usr/src/linux is pointing to the XFS-capable 2.4.5 kernel source tree (/usr/src/linux -> /usr/src/linux-2.4.5-xfs)

Then for each package (acl, attr, xfsprogs, xfsdump)

I don't build or install the 'dmapi' package - since I don't enable the XFS dmapi features in my kernel config.

 

Creating an XFS filesystem

The XFS filesystem that you'll be creating is on a spare partition (or hard-drive) - so don't rush into this thinking that we're doing a magic ext2 -> xfs conversion ;-)

You might want to create a larger internal log than the default... for better preformance - with a command like:

 

Migrating your stuff to the new XFS filesystem

You'll need to pick a point in your existing ext2 filesystem that will become the root (/) of your new xfs filesystem - I just choose /mnt on my system.

I created an xfs filesystem at /dev/hda6 - so I do something like the following:

Keep in mind that the command you'll be using to transfer your data from your ext2 partition(s) to the xfs partition won't be 'crossing' mount-points in the filesystem - so you'll want to start by copying your / filesystem.

If you happened to have partitions besides /, the mount-points or directories will be created... but nothing will actually be copied there (/usr, /home, etc...)

For each 'extra' partition you might have - you would do something like the following:

 

Adjustments to your XFS /etc/fstab and /etc/lilo.conf (/mnt/etc/fstab, /mnt/etc/lilo.conf)

You need to make some adjustments to the /etc/fstab and /etc/lilo.conf files on the new XFS filesystem... so that you'll actually start using the XFS filesystem after a restart.

The new /etc/fstab (/mnt/etc/fstab) entry will look like:

The new /etc/lilo.conf (/mnt/etc/lilo.conf) needs a similar adjustment:

This is where my contribution to the HOWTO comes in - with regard to a separate /boot partition ;-)

I have a separate /boot partition at /dev/hda2 - but it wouldn't have been appropriate to 'copy' the contents onto the xfs partition with the 'cpio' stuff earlier - but it is important to write to the /boot partition when we update our LILO configuration.

In short... I needed to mount my /boot partition at /mnt/boot before running 'lilo' with my updated /mnt/etc/lilo.conf

Now I can run 'lilo', treating /mnt as the root of the new XFS filesystem