Moving the Journal
In Mac OS X 10.2.2 journaling was added to the Mac OS X Extended file system (I first read about it here on afp548). Journaling introduced a lot of great stuff, most notably improved resiliency to crashing. This resiliancy comes from the fact that a journaled file system uses part of a disk to write changes that are intended to go into the actual file system. This way if a crash occurs while a transaction to the file system is occurring the file system will usually easily and quickly recover by using the journal to bring the file system back into a consistent state.
Read on for more...
Journaling helps keep those file systems healthy, but journaling causes additional load on the disks it is running on. The load increases dramatically with large quantities of data writes to disks, creating a bottleneck at the file system for heavily write intensive processes. And now we have an option to mitigate that bottleneck: move the journal to a dedicated disk. Well, it doesn't necessarily have to be completely dedicated, just not used much).
First let's look at what we've got in our system using diskutil. If you run the diskutil command with the list option then you will see a listing of the disks, associated partition schemes and the partitions on each:
diskutil list
In the following output we see an Xserve with a single SAS drive (/dev/disk0) and a SSD (/dev/disk1):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *80.0 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 79.7 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *64.0 GB disk1
1: EFI 209.7 MB disk1s1
2: Apple_HFS SSD 63.7 GB disk1s2
If the partitioning scheme for the disk is not a GUID_partitioning_scheme then you will not be able to move the journal to the disk. You can erase the drive and change the partitioning scheme either through Disk Utility or through diskutil using the optional partitioning scheme parameter. If you add a 3rd party SSD post-purchase to your Xserve then from what I've seen they've all shown up with FDisk or Master Boot Record schemes and will likely need to be changed to GPT or GUID Partitioning Table. So you've got your disk, you even have it mounted. The easiest next move is to run the diskutil command along with the movejournal verb. In this example, we're going to move it to an external source (as in external to the disk that it's journaling) and then list the destination for the journal followed by the source of the journal:diskutil moveJournal external /Volumes/SSD /Volumes/Macintosh HD Your diskutil listing should now appear similar to the following:#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *80.0 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 79.7 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *64.0 GB disk1
1: EFI 209.7 MB disk1s1
2: Apple_Journal 536MB disk1s23: Apple_HFS Untitled 63.7 MB disk1s3
You can rename that Untitled disk that was created to something trivial. For this server it acts as a clone of the operating system. That's not a very transactional operation since it's an active-passive relationship with the boot volume.We were able to move the Journal without a reboot. However, moving the journal back might cause a reboot if your journal is on the boot volume. The reason is that in order to make it work on my system I had to actually do it from target disk mode given that the disk you are moving the journal to needs to be unmounted for the move operation (it seems). The command was the diskutil with the moveJournal verb, but this time we told it to move to internal rather than external and listed only the volume name:diskutil moveJournal internal /Volumes/Macintosh HD