Slashdot Mirror
BSD Journaled File System Ready For Testing
Dan writes "The Journaled File System for FreeBSD (JFS4BSD) Project has the goal of porting the JFS Technology from IBM/Linux to FreeBSD. It uses a log-based, byte-level file system that was developed for transaction-oriented, high performance systems. Scalable and robust, its advantage over non-journaled file systems is its quick restart capability: JFS can restore a file system to a consistent state in a matter of seconds or minutes. The jfsutils is under a compilable state on FreeBSD."
JFS, other journalled file systems, and Softupdates have the same goal -- keeping file metadata structures consistent on the disk. JFS does not attempt to maintain file data integrity in the event of a crash -- that is the job of a DBMS. Go and read the web page on JFS from IBM that is linked to in the original posting.
Granted, journalled FS's and softupdates go about things in different ways. Softupdates trades off potentially increased disk space usage and higher disk and CPU activity after a crash (performing the background, reduced set of checks in fsck) against a smaller relative performance penalty vs. a non-journalled FS in normal usage as compared to a journalled file system.
My own $0.02 is that this is a nice scratch-the-itch, check-the-box-for-PHB's addition, but for most normal usage softupdates is a better choice. See the papers by Ganger and Patt and McKusick for more details. (Links copied from the OpenBSD FAQ pages.)
--Paul
Don't believe me? Read the JFS overview from IBM, which says:
The only benefit JFS has over UFS+SU in this context is faster on-crash fsck times. And it only takes about a minute to check a 60GB UFS filesystem after a crash, which is about 3 orders of magnitude better than e2fsck (I don't know how speedy jfs.fsck is in non-replay mode).The chief benefit of JFS for FreeBSD is going to be portability. Which is a pretty big one, although I don't see JFS supplanting UFS before FreeBSD 6.0, if then.
My understanding is that a journalled FS records every file block allocation and deallocation on the volume in a separate journal. This way, if an operation does not complete (say, due to a power failure), the disk can be restored to a known consistent state very easily. A consistent state is one where no blocks are allocated that should not be, and no blocks that are in use are listed as unallocated.
Softupdates does a partial re-ordering of operations so that all allocations happen before deallocations. Thus, in the event of a crash there can never be any blocks that are in use but marked as unallocated. The only possible inconsistency is that there may be blocks that are unused but marked as allocated. In the event of a crash, no fsck is performed as a part of the boot sequence, but a special background version of fsck is run to find any blocks that unused but marked as allocated and mark them as unallocated, which is a safe operation.
Comparing the two methods of operation, a journalling FS pays a speed penalty under normal operations, as it needs to do two writes to the volume for every write access from the application, one to write the journalling data and one to write the actual write. However, on a restart after a crash, the journal is just used to roll back the volume's allocations to a known good state and the OS continues on its merry way.
FFS with softupdates is faster under normal operations, as there is only one write to the volume for every write access from the application. However, in case of a crash there is the potential for a large quantity of disk blocks that will need to be scavenged, thus making the volume look like it has less free space than it actually has, plus the background fsck needs to run and fix up the allocations.
Read the Ganger and Patt and McKusick papers linked to in my original post for more details.
--Paul