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 disk1s2
3: 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
Hardware:
Notes:
Results:
Here are Apple’s instructions for moving the journal:
http://support.apple.com/kb/HT3790