Slashdot Mirror

← Back to Stories (view on slashdot.org)

BSD Journaled File System Ready For Testing

Posted by timothy on from the dear-diary dept.

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."

2 of 113 comments (clear)

  1. A gentle correction... by plsuh · · Score: 5, Informative

    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

  2. Re:A mixed blessing. by ctr2sprt · · Score: 5, Informative
    (SoftUpdates aims to keep all file metadata consistent at all times; journalling aims to keep all file -data- consistent at all times.)
    That's just not true. Soft updates works by ordering writes so that the metadata is always in a consistent state. This has the effect of also keeping the data in a consistent state, since data sits in the to-be-ordered queue right along with the metadata. Journaling filesystems typically track only the metadata (though some, like e3fs, can also do ordered data writes), which means that data can be lost as the metadata is returned to a consistent state.

    Don't believe me? Read the JFS overview from IBM, which says:

    JFS only logs operations on meta-data, so replaying the log only restores the consistency of structural relationships and resource allocation states within the file system. It does not log file data or recover this data to consistent state. Consequently, some file data may be lost or stale after recovery, and customers with a critical need for data consistency should use synchronous I/O.
    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.