In theory, there is no difference between theory and practice. But in practice, there is. Jan L. A. van de Snepscheut
As described in part 1 of this entry, I attempted to format a TrueCrypt-encrypted drive to the standard Linux ext3 format. As alluded to there, this turned out to be more difficult than I expected.
When I attempted to format the drive, the mkfs command would get a few seconds into it and simply freeze. More than that, the entire Linux system would freeze, requiring a reset to get it started again — that’s generally not an easy thing to do by accident.
The only other file systems I knew how to use were ext2 (the earlier, non-journaling version of ext3) and the FAT file system (a.k.a. vfat, used in DOS and Windows and almost universally available in other OSes — but it doesn’t support Linux file-permissions, which is what prompted this experiment to begin with). Formatting the drive to vfat gave me no problems; formatting it to ext2 locked the system, the same as ext3 did.
Some research on the TrueCrypt forums showed that this was a well-known problem. It seemed to be related to the Linux kernel rather than TrueCrypt, and this thread suggested a work-around — which, while it did slow down the format operation, didn’t prevent the lockup here. But since formatting to vfat worked, and I knew there were other file-systems available for Linux, I decided to try one of those instead.
Some research turned up three other options: ReiserFS, XFS, and JFS.
ReiserFS is apparently very popular with Ubuntu users. It had also come up in several conversations with my Linux-using friend, but he said he had lost data while using it. I read dire warnings from one other TrueCrypt user too, saying that you would lose data if you tried using it. That was sufficient to keep me away from it.
XFS and JFS both seem to do a very good job on larger systems, though they’re slower than ext2/ext3 for smaller ones (like this one). JFS seems marginally faster, from the benchmarks that I’ve seen, so I decided to try that first:
sudo mkfs.jfs /dev/mapper/truecrypt0 sudo: mkfs.jfs: command not found
Huh? Hm.
sudo mkfs.xfs /dev/mapper/truecrypt0 sudo: mkfs.xfs: command not found
Okay, apparently they’re not installed by default. A little more research showed that I needed to request the “jfsutils” package. After doing so…
sudo mkfs.jfs /dev/mapper/truecrypt0 mkfs.jfs version 1.1.11, 05-Jun-2006 Warning! All data on device /dev/mapper/truecrypt0 will be lost! Continue? (Y/N) y Format completed successfully. 6291455 kilobytes total disk space.
After re-mounting the drive, everything seemed to work. Success!
Next up, and likely the subject of a part 3, will be figuring out how to use the encrypted drive as my home partition, so that all of my data will be on it.
Good thing you didn’t choose XFS, XFS really needs an uninterruptible power supply, it write-caches very aggressively. Without the UPS you loose data if you have a crash or loose power. IBM’s JFS is relatively immature on Linux, but people seem to be starting to warm up to it so maybe the bugs it had at first are worked out. Since of course, you can’t seem to run ext3 (or ext2) on it, JFS is probably a good choice.
Using an encrypted partition as your home partition may be tricky. GRUB needs to be able to read the file-system where the kernel lives. Of course, if your /boot tree is on another partition, you could be able to pull it off? I’d recommend some forum reading / googling before typing any commands at random. 😉
Oops! Misread “home partition” as “root partition” – your home partition should be not a problem.
XFS seems to be quite popular too, probably the second most popular alternative file system after ReiserFS. But a couple of comparisons that I read suggested that JFS was both faster and more processor-efficient, and feature-wise it’s nearly identical to XFS.
Most of my systems are plugged into their own uninterruptable power supplies, and the laptop has it’s internal battery as well, so that’s not generally a problem here.
Yes, I only plan to encrypt the home partition. There isn’t much point to encrypting the boot file system; that would presumably be a lot harder to do, and it’s only my data that I’m worried about.
Maybe I should check out JFS in my next distro-hop. 😉
I already was planning to try Slackware-current once they had a release candidate for 12.0. Now that they do, I’m running JFS. I can’t really say I notice much of a difference, but it seems to be working OK so-far. (Hope my computer doesn’t hear me say that. 😉 ) I’m a Slackware subscriber, which means that once 12.0 is released, I’ll get it in the mail, but I wanted to see a preview. 🙂
JFS seems pretty good, but you probably won’t notice any improvement over ext3 on single-user systems. Like XFS, it was designed for medium to large systems, and only really shines there, as far as I can tell. If I had been able to get ext3 working properly with TrueCrypt, I wouldn’t have bothered even looking at anything else, though I’m glad I did now, if only for the knowledge.
I would have used ext3 also because I have a program that can read ext3 but not JFS from Windows. (I didn’t think of that problem! No big deal, I can read NTFS from here fine and FUSE’s NTFS-3g plug-in can write to it if need be.)