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.
According to the comment on http://daily.daemonnews.org/view_story.php3?story_ id=3539 the JFS code itself isn't ready yet, but the jfstools are. So you can take a JFS disk from a Linux box and use the jfstools, but you can't mount the JFS right now.
This basically means that you cannot distribute the FreeBSD kernel with both GPL and proprietary code, but there is no problem distributing it if you leave the GPL part out of the compile. See Greg Lehey's Diary, namely the Tuesday, 18 December 2001 entry.
Yes.
wrong, if you write to the middle of a file then both UFS+SU and a metadata-only journal won't keep the data consistent in a crash (Ie. you can have some old data and some new data).
If you have a real journal (Ie. data=journal in ext3) then you get consistent data writes too, which is very different. There are other ways to achieve the same thing (WAFL, the unfinished Tux filesystem for Linux) you appear to be correct that JFS only supports a metadata journal.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
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
This decision was made due to space concerns. For users with small filesystems, it was a common problem, during an installkernel, to run out of space on / because the previously unlinked blocks from things such as /modules/ or /boot/kernel/ were not deallocated yet (deallocation can take time using softupdates, but happens eventually). The solution to this problem was to have the root filesystem default to not having softupdates. This was just due to the fact that you do not want your root filesystem filling up, and this really made it a pain for many users to upgrade. Perhaps a better decision would be to have sysinstall toggle it based on how large the filesystem is, but it's really a tough call. But anyway, there's some fairly recent history for you :)
Cheers,
-JD-