JFS Installation or Conversion for Boosting Performance
IBM's Journaled File System, or JFS for short, is an outgrowth of its AIX operating system. JFS, Ext3, XFS and ReiserFS, are the big 4 of journaled file systems, and each has its own characteristics that make it suitable for different users. JFS is very fast, light, and efficient. Nevertheless it performs extremely well under a wide variety of situations, and draws lightly on the CPU on comparison to the others. See the links at the end of this article for benchmarking articles.
Why & why not?
Particular strengths of JFS include:
- a marked boost in network transfer speeds, similar to those listed for XFS here ,
- lowest CPU usage from among the big 4,
- very fast operations (copy and remove) on large files (e.g. ISO image, 700MB),
- extremely scalable, with filesizes in the terabytes or petabytes,
- minimal loss of capacity when creating a filesystem (less than 1% lost - virtual tie for 1st place with XFS and ReiserFS),
- comes with jfsutils, utilities for managing the JFS filesystem,
- very fast filesystem creation, mounting and unmounting, and
- (very important!) a very thorough block-checking feature on mkfs.jfs (invoked by using mkfs_jfs -c )
- not supported in Windows or OS X,
- JFS partitions do not support "shrink", and
- currently JFS is supported in the 126.96.36.199_v3 firmimg.bin when booted in both hdrootfs mode and EM mode, but the jfsutils are not yet available in EM mode (we are hopeful for addition of jfsutils to the RAM disk in the near future - they up take about 1250kB).
What does this mean for me?
- Speed and security for your data partition: JFS partitions are fast, journaled, CPU-stingy, and a very good fit for a NAS device like the LS. Currently, they are not the best choice for your root system partition, since the RAM disk used for EM mode doesn't have the tools included yet (though is likely to change in the near future).
- Lower CPU Utilization: If you use your Linkstation as a music server in addition to the normal NAS function, you may notice that during backups or network transfers, there maybe a momentary dropout of the music. Lower CPU utilization can mean a lower likelihood of music dropouts.
- Personal responsibility: First, filesystem choices are personal ones. Whatever filesystem you choose, make sure you have a backup strategy and that you know how to effect repairs, if they are ever needed. Few things in life or Linux are completely "bomb-proof" or "idiocy-proof".
- back up all of your data and your system
- Freelink/Debian or another distribution that supports it
- a 2.4 or 2.6 kernel w/ JFS support
- a partition on which to create a JFS filesystem, or a currently used partition you wish to convert to JFS,
- whatever time you need to backup your data,
- about 30 minutes for preparation, setup, creation and confirming,
- more, around 1hr/100GB, if you want to check for bad blocks when creating the filesystem, and perhaps
- lots more if you choose to use convertfs.
In either stable or testing, get your packages and install them:
apt-get install mod-init-tools jfsutils
To test if you are ready to create the filesystem, issue
and you should see no output. An error can mean that JFS is not supported on your kernel.
Please feel free to add content here - your contribution is appreciated.
Creating a JFS Partition from Scratch
This is a preferred method, but it is data-destructive. Make sure you backup any data on this partition before proceeding. 0. Unmount the partition, if necessary. You can see what you have currently mounted by issuing a
and you may see something like this:
Filesystem Type Size Used Avail Use% Mounted on /dev/hda1 ext3 5.0G 952M 3.8G 20% / tmpfs tmpfs 62M 4.0K 62M 1% /dev/shm /dev/hda3 ext3 228G 9.7G 218G 5% /mnt tmpfs tmpfs 10M 2.5M 7.6M 25% /dev
Assuming that the partition you wish to work on is /dev/hda3, unmount it:
1. Use fdisk to create a new partition, on (for example purposes) /dev/hda3 (alter to fit your circumstances):
You can also choose to split this partition if you want to. We will assume that you know how to use fdisk to delete, create, split and/or type a partition.
2. Use mkfs.jfs to make the filesystem, with block checking enabled (again, assuming that it is hda3 that you are targeting):
mkfs.jfs -c /dev/hda3
While the creation phase is quite fast, the block checking can take several hours for a 240GB partition. Block checking is encouraged and is worthwhile if data integrity is important to you. You can choose to omit the -c flag if you are extremely confident that your hardware has no issues.
3. Edit your fstab to reflect the changes:
Change the following line
/dev/hda3 /mnt ext3 defaults,noatime 0 0
so that it reads like this:
/dev/hda3 /mnt jfs defaults,noatime 0 0
4. Reboot and use df -Th see if your new JFS partition is mounted and ready to use:
df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/hda1 ext3 5.0G 952M 3.8G 20% / tmpfs tmpfs 62M 4.0K 62M 1% /dev/shm /dev/hda3 jfs 228G 9.7G 218G 5% /mnt tmpfs tmpfs 10M 2.5M 7.6M 25% /dev
This output means that your JFS partition is mounted and ready to use.
Converting an existing partition to JFS w/ convertfs
Note that this method doesn't check for bad blocks during conversion. It does work, seems generally safe, and has been tested somewhat. YMMV, and backup your data.
You will need the the mod-init-tools and jfsutils, as shown above. Read this wiki article on Using XFS instead of Ext3, and understand that you will be following it for the most part, except that you will have to change all instances of XFS to JFS, and use jfsutils instead of xfsprogs. Basically, use a command like:
convertfs /dev/hda3 ext3 jfs
similar to what is shown in the article Using XFS instead of Ext3. As you follow that article though to the end, using JFS instead of XFS, note that:
- this process is time consuming if the partition is full,
- conversion should only be attempted on a partition that is well under 1/2 full,
- the convertfs package/program has some (perhaps undeserved) reputation of being perhaps a bit buggy,
- any data on the partition could be lost, but might be safe, and
- (this is a biggy!) the process doesn't check for bad blocks as it converts.
After rebooting, try a network transfer using Samba, NFS or AFP. You may experience a boost of anywhere from 20% to 150% improvement in speed. Enjoy!
Articles and References
- Linux File System Benchmarks
- Benchmarking Filesystems: Justin Piszcz's 1st benchmarking article
- Benchmarking Filesystems Part II - a followup/2nd article by Piszcz
- Debian Administration article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch
- Flexible File System Benchmark
- Benchmarking Filesystems In 2.6.0-test2
- Journaling Filesystem Shootout