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."
This strikes me as both a good and a bad thing. /home and JFS on the maildirs, for example. :-)
Good, because journalled filesystems are a Good Thing. I use FreeBSD exclusively on both desktop and workstation, and while SoftUpdates is very good, it and journalling have different aims. (SoftUpdates aims to keep all file metadata consistent at all times; journalling aims to keep all file -data- consistent at all times.) Choice is always good, and I could see myself using SoftUpdates on
However, this is a bit of a Bad Thing in that one of FreeBSD's simplicities has always been the One Filesystem, UFS. Granted, UFS has evolved some (UFS-Softupdates and now UFS2) but there was never a question as to which filesystem to choose: UFS has enough tunables, most of them automated, that you can optimize it for small-file, large-file, high-latency, low-latency, etc. I've found it to be capable of keeping up with the various Linux filesystems in their own areas. But if this is merged into -current, there will be a choice to make when preparing a slice. This is one of those things that's hard to change after the fact.
As for me, I'll stick with UFS2 until I see how this shapes up, but tally-ho!
One of the most impressive things about Linux is the XFS filesystem for it. It is thoroughly tested, production quality, and extremely robust. It is a please to deal with XFS. I personally have tested XFS for robustness and speed, and I have done things such as set up scripts to get, untar, copy erase, and start and stop various daemons and databases and then while this looping miasma was going on RIP THE HARD DRIVE from the system (SCA, SAF-TE, hop swappable). I have yet to see a lengthy FSCK or a corruption. Simply the best!
o bj-i3 86/sys/compile/JUNIPER
UFS2 is interesting, and provides a lot of improvements to UFS1, the soft updates are fairly effective at keeping things consistent and there is a background fsck in FreeBSD that works quite well.
A filesystem which is just as robust as XFS in terms of durability is JFS, but sadly I have found this filesystem to be a bit short on the performance side. I believe the main function of JFS is to provide support for those moving from older IBM systems to newer things that possibly include the us of Linux over AIX or OS/2.
I personally will not consider Reiser or EXT3 and could go into detail as to why. I have strong opinions as to what types of filesystems belong in production, and these will not qualify.
So, while JFS for FreeBSD is a good thing, I would like to see at some point an attempt to move XFS to FreeBSD, and if I had that capability, I would have already started.
FreeBSD is coherent, well documented and with things such as Vinum, and JFS-like filesystems and hopefully someday XFS, it really does quote a bit and is released under a flexible, corporate-friendly license (which I believe helps to foster and promulgate further development, not stifle or prevent it).
On of the series of equipment that I am most impressed with is the Juniper routers. They are the best routers available in my estimation (65xx switches are my most favored switches). I feel very at home with JunOS because it is largely FreeBSD:
JuneOS version 5.6R1.3 built by builder on 2003-01-02 20:19:20 UTC
Copyright (c) 1996-2001, Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
JUNOS 5.6R1.3 #0: 2003-01-02 20:38:33 UTC
builder@zu.juniper.net.:/build/zu-b/5.6R1.3/
Legalize the constitution. Think for yourself question authority.
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
I personally will not consider Reiser or EXT3 and could go into detail as to why. I have strong opinions as to what types of filesystems belong in production, and these will not qualify.
/., and this will not qualify.
How can a stupid statement like this get moderated to the top? Unsubstantiated claims like this should only be allowed to criticize Microsoft. Comments critical of Linux must be backed up with hard data.
I personally will not consider this comment and could go into detail as to why. I have strong opinions as to what types of comment belong in
Joe Batt Solid Design
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