Information
on using the logform command
Technote (FAQ)
Question
When should I run the logform command?
Answer
What
is logform?
The
/usr/sbin/logform command formats a JFS or JFS2 filesystem log device (or
inline log for JFS2 filesystems using them) so the filesystem can log
transactions that modify filesystem meta-data. In other words, this is the journal in Journaling File System.
When running the fsck utility to repair a damaged filesystem, one of the first things it does is to immediately call /usr/sbin/logredo. Logredo is a "helper" application that goes through the log device and finds updates to the filesystem that have not been committed, and commits them. These updates may be uncommitted because of a system crash, or storage outage for example.
Many times you can watch fsck call logredo like:
# fsck /encry
The current volume is: /dev/fslv05
Primary superblock is valid.
J2_LOGREDO:log redo processing for /dev/fslv05
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
File system is clean.
If you run logform before giving logredo a chance to commit changes to the filesystem you may damage the filesystem and cause data loss!
When should logform be used then?
When logredo is having trouble replaying the transaction log.
# fsck /dev/hd3
The current volume is /dev/hd3
j2_logredo: logredo processing for /dev/hd3
j2_logredo.cpp error in j2logredo line 647 open read device
failure replaying log: -1
exec module "/sbin/helpers/jfs2/logredo:" failed
logredo failed (rc=255) fsck continuing
Output like this can signify that the log device may be bad, or it may actually be missing from the vg. In this case since fsck is not going to be able to call logredo successfully we'll have to run logform and risk loss of any changes that weren't committed to the filesystem. In some cases fsck may coredump when it calls logredo, due to the nature of the damage.
One item to remember is that since multiple filesystems can share the same journal (or log device), ALL filesystems using it must be unmounted before running logform, if you are running it to repair or reconstruct the journal. The easy way to check that no one's using it is use lslv:
# lsvg -l vgname
testvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
loglv03 jfslog 1 1 1 open/syncd N/A
This log device is open and being used, because you can see the state is "open".
loglv01 jfs2log 1 2 2 closed/syncd N/A
This log device is "closed" and is safe to reformat.
Summary
So in a nutshell, if you do decide to run logform to reformat the log, do it AFTER trying at least 1 fsck.
# fsck /fsname
fsck fails with errors
# logform /dev/loglv (or /dev/lvname in the case of inline log)
# fsck /fsname (try fsck again)
When running the fsck utility to repair a damaged filesystem, one of the first things it does is to immediately call /usr/sbin/logredo. Logredo is a "helper" application that goes through the log device and finds updates to the filesystem that have not been committed, and commits them. These updates may be uncommitted because of a system crash, or storage outage for example.
Many times you can watch fsck call logredo like:
# fsck /encry
The current volume is: /dev/fslv05
Primary superblock is valid.
J2_LOGREDO:log redo processing for /dev/fslv05
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
File system is clean.
If you run logform before giving logredo a chance to commit changes to the filesystem you may damage the filesystem and cause data loss!
When should logform be used then?
When logredo is having trouble replaying the transaction log.
# fsck /dev/hd3
The current volume is /dev/hd3
j2_logredo: logredo processing for /dev/hd3
j2_logredo.cpp error in j2logredo line 647 open read device
failure replaying log: -1
exec module "/sbin/helpers/jfs2/logredo:" failed
logredo failed (rc=255) fsck continuing
Output like this can signify that the log device may be bad, or it may actually be missing from the vg. In this case since fsck is not going to be able to call logredo successfully we'll have to run logform and risk loss of any changes that weren't committed to the filesystem. In some cases fsck may coredump when it calls logredo, due to the nature of the damage.
One item to remember is that since multiple filesystems can share the same journal (or log device), ALL filesystems using it must be unmounted before running logform, if you are running it to repair or reconstruct the journal. The easy way to check that no one's using it is use lslv:
# lsvg -l vgname
testvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
loglv03 jfslog 1 1 1 open/syncd N/A
This log device is open and being used, because you can see the state is "open".
loglv01 jfs2log 1 2 2 closed/syncd N/A
This log device is "closed" and is safe to reformat.
Summary
So in a nutshell, if you do decide to run logform to reformat the log, do it AFTER trying at least 1 fsck.
# fsck /fsname
fsck fails with errors
# logform /dev/loglv (or /dev/lvname in the case of inline log)
# fsck /fsname (try fsck again)