The arrow of time

Ivan Voras' blog

Why UFS in FreeBSD is great

ZFS is of course the rock-star file system in FreeBSD, with numerous features and new ones frequently coming in, but UFS is also a pretty solid deal which is perfectly usable for a wide number of tasks. Here are some of my favourite UFS features.

#1: UFS is a pretty old file system which has been continually incrementally upgraded though the years. One of its best features is that its memory usage is conservative (compared to ZFS). As an "organic" file system it has evolved with the BSD kernel and both are pretty much tied together and work best with each other.

#2: Soft Updates is an extremely elegant solution to file system consistency and actually the optimal solution in some cases. Consider a database which has its own log (like PostgreSQL and MySQL's InnoDB) - using journalling would simply log everything twice, while soft updates simply passes the data through. In addition to that, soft updates has an interesting property regarding short-lived (e.g. temporary) files: if you create a file, write a small amount of data to it, then delete it all in a short time span, neither data nor metadata from this file will ever touch the disk drive platters. No inode, free space bitmap or directory files will be changed if a file is short lived enough to not be seen by a checkpoint and it's not explicitely fsync-ed.

#3: Soft Updates Journalling was created to get around the few corner cases which Soft Updates alone cannot track. A fsck is sometimes needed when a file system is not unmounted cleanly with Soft Updates alone (and usually happens in the background), but with the addition of journalling, there are much fewer such cases. This feature is not a "log" for data in the sense like ext3/4's log can work or how ZFS works, but a journal of some (not all) operations which need special care and recovery. Consequently, it is very small and efficient.

#4: Snapshots are an integral feature of UFS, and happen on the file system level. By using snapshots before backing up databases, you can be sure that a consistent image of database files is recorded at the point of time where you started the snapshot. If the database is ACID enough, this is all that is needed to ensure a successful backup. ZFS's snapshots are quicker to make and writable (while UFS's are a bit slow and read-only) but if you are doing nightly backups, they could be good enough for many cases.

#5: UFS supports TRIM natively, which allows it to efficiently delete data on SSDs.

#6: UFS has both fragments and blocks, so files less than a block size (usually 32 KiB on recent FreeBSD versions) can be stored in individual fragments (4 KiB on those systems). These sizes are configurable at file system creation, so it is perfectly ok to create a file system which is optimized for storing files less than 1 KiB in size, while having a decent block size of 8 KiB.

#1 Re: Why UFS in FreeBSD is great

Added on 2013-10-25T02:48 by Eric Camachat


#2 Re: Why UFS in FreeBSD is great

Added on 2013-10-25T11:27 by kamikaze

I love the idea of SU+J, but my personal experience is that it causes fsck to overlook file system inconsistencies after a crash/panic and hence causes the system to boot into a broken file system.

As soon as a broken inode is touch (by something as simple as stat/ls) the resulting panic is guaranteed. I can see why HD write-caching can cause such errors in cases of power failure. But that isn't the case during a panic, hence my conclusion that SU+J is not ready for use.

#3 Re: Why UFS in FreeBSD is great

Added on 2013-10-25T12:37 by wilx

While UFS is decent enough, some of the features you name above only work well on paper. Using UFS snapshots tends to lock up the system. There were SU+J lockups reports as well.

#4 Re: Why UFS in FreeBSD is great

Added on 2013-10-25T23:50 by Freddie

ZFS's snapshots are quicker to make and writable (while UFS's are a bit slow and read-only)

Note: ZFS snapshots are read-only. You have to manually clone a snapshot in order to make it writable.

#5 Re: Why UFS in FreeBSD is great

Added on 2013-10-28T12:24 by J. Bouquet
I've a combination of .journal and SUJ; many are "(g)journal flag on filesystem but no provider below" or some such message upon mounting. Howsoever, I hardly ever lose data. What I'd prefer to see is a flowchart which has the error messages within a grid of sorts, so one could resolve UFS, SUJ, even ZFS errors, migrations, GPART cli solutions, etc to simplify installs and repairs and migrations of disks, partitions, filesystems etc.

#6 Re: Why UFS in FreeBSD is great

Added on 2013-11-01T05:10 by Pedro Giffuni

UFS has shown a great capacity to continue evolving. It has seen layout changes, addition of seek data|hole, performance improvements, recently even some fsck speed ups, and it still remains compatible with previous versions.

I have been working on the BSD-licensed ext2fs implementation and the more I consider the features in ext3/4, the more I like UFS2. Softupdates is just simply amazing.

#7 Re: Why UFS in FreeBSD is great

Added on 2013-11-23T08:48 by Zahemszky Gábor
In #3 Soft Updates Journalling you told "fsync", but it should be "fsck".

#8 Re: Why UFS in FreeBSD is great

Added on 2013-11-23T08:54 by Ivan Voras


#9 Re: Why UFS in FreeBSD is great

Added on 2014-04-07T21:55 by IT_Architect

I agree, especially in a virtual machine where the virtual environment provides nearly everything that ZFS brings. However, one key thing missing in UFS2, and that is transparent compression/decompression. People can say disk space is cheap all they want, but we always find useful purposes for the space, no matter how much there is.

#10 Re: Why UFS in FreeBSD is great

Added on 2014-04-23T10:09 by Wojtek

No ZFS is not a rock star. Is marketing star and an example how not to implement safe file system.

And it is actually very slow compared to UFS in real use cases. Not mentioning enormous memory and CPU usage.

Post your comment here!

Your name:
Comment title:
Type "xxx" here:

Comments are subject to moderation and will be deleted if deemed inappropriate. All content is © Ivan Voras. Comments are owned by their authors... who agree to basically surrender all rights by publishing them here :)