Speed up recovery with JFS2 Filesystem NOLOG feature
AnthonyEnglish 270000RKFN Visits (5434)
If you need to copy or restore data to a file system in a hurry, then you could mount the target file system with the NOLOG option. This was one of three suggestions I made in an earlier post for when you need to copy data quickly, but the Technote covers the NOLOG more comprehensively than I did in that post..
NOLOG for dummies
What is the NOLOG option? For that matter, what is a jfs log for anyway?
As the technote explains, every transaction sent to the filesystem also triggers a log event to be written to the log device. The log device may be a separate logical volume of type jfs2log, or it might be an INLINE log. Turning off that logging by using an option on the mount command should have a positive impact on performance. Here's how you'd do it:
Smart and speedy
If it's a file system that' you're copying or restoring to, then your data is already somewhere safe - such as in a backup format - so in the unlikely event that the file system goes AWOL during the restore, you could always recover it or start again. Removing the need to update the JFS log would be smart, as it ought to speed up your copy or restore of data. Once the restore is over, you'd be wise to unmount the file system and mount it again using its default log. To do that, you simply omit the -o log=NULL when you run the mount command.
But don't be a dummy
If, on the other hand, the filesystem is just scratch space or a temporary file system, you could permanently mount it with log=NULL. Be warned, though. "Temporary" or throwaway file systems have a magnetic attraction to people looking for somewhere to store some critical component of a production system. There's nothing so temporary as a permanent solution.
The Technote is very short and well worth a read. It's Technote T1012643 on the JFS2 Filesystem NOLOG feature.