Again I would reiterate that using xfs on large partitions in unwise. In order to attempt repair this disk (it remains to be seen if it will be successful) I had to boot into single user mode, cryptsetup luksOpen /dev/sdx xfscrypt, xfs_repair -t 60 -v /dev/mapper/xfscrypt. This is a dual-code 2.4GHz machine with 2GB of DDR2 RAM. The repair process has been running for over 10 hours so far, is 75% done with “Phase 4”, and estimates almost another 2 hours to go. It has also consumed 1.9GB of resident memory and 6.6GB of virtual memory. And of course, my computer is unusable at this time (I’m entering this from my laptop). Not exactly the kind of thing one wants from a filesystem.

Update: After running for 15 hours I gave up and decided to take the time to move the data off the disk, reformat it with ext3, and restore the data.

After trying my best to run xfs_repair on a large xfs partition (and failing) I realized that the decision to use xfs was a mistake. In no way should anyone use xfs unless: 1) they are sure there will be no compatibility issues, 2) they use it on a 64-bit system, 3) they use it on a system with lots of RAM, 4) they don't use it on a large partition, 5) they are not using it with block device encryption. Believe me, I've tried with each of these issues individually and in combination and have concluded that it was not worth the extra effort.

One interesting aspect of this one though is that it benchmarks filesystem with noatime on and off:

• Serverwide Performance Benchmarking

The conclusion is that noatime doesn’t improve performance under the set of benchmarks used which are meant to be representative of a website with a database backend.