GSoC proposition: multiplatform UFS2 driver

[Richard Yao]

On 03/14/2014 11:27 AM, RW wrote:
> On Thu, 13 Mar 2014 18:22:10 -0800
> Dieter BSD wrote:
> 
>> Julio writes,
>>> That being said, I do not like the idea of using NetBSD's UFS2
>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2
>>> second only to ZFS in desirability.
>>
>> FFS has been in production use for decades.  ZFS is still wet behind
>> the ears. Older versions of NetBSD have soft updates, and they work
>> fine for me. I believe that NetBSD 6.0 is the first release without
>> soft updates.  They claimed that soft updates was "too difficult" to
>> maintain.  I find that soft updates are *essential* for data
>> integrity (I don't know *why*, I'm not a FFS guru). 
> 
> NetBSD didn't simply drop soft-updates, they replaced it with
> journalling, which is the approach used by practically all modern
> filesystems. 

The result is the same in that they no longer have soft-updates. I
consider this to be a step backward. Journaling is predicated on the
idea that you can fix things after they go wrong. I consider this to be
the wrong approach to consistency. However, journalling that stores all
changes does improve performance in comparison to soft-updates in short
lived files. Such benefits could be obtained through the use of an
intent log, similar to the ZFS Intent Log.

An intent log is very similar to a journal in its ability to improve
performance. However, it functions differently because its main purpose
is to act as a buffer to store information about things that the
filesystem has promised it would do and then enable them to be done
asynchronously for improved performance. A journal is meant to enable a
filesystem that is inconsistent to be brought into a consistent state.
If you are always consistent like ZFS, you can forgo the need to be made
consistent and reap the performance benefits from an intent log.

At present, all synchronous operations on ZFS that are 32KB or less are
sent to ZIL first and then written back asynchronously. This enables ZFS
to obtain extraordinardily impressive performance in workloads in which
many believe CoW filesystems to be at an inherit disadvantage. For
example, here is a quote from a discussion on the btrfs development list
after ZFS outperformed btrfs in Phoronix's tests:

> Not a whole
> lot we can do about this since unaligned writes means we have to read in pages
> to cow the block properly, which is why we fall back to buffered.  Once we do
> that we end up having a lot of page locking stuff that gets in the way and makes
> us twice as slow.

http://thread.gmane.org/gmane.comp.file-systems.btrfs/27546/focus=27555

Previous tests by Phoronix had placed ZFS in last place and the ZIL is
not the reason for this change in performance. The actual reason for the
change in performance was that I had modified ZFSOnLinux to set ZFS'
internal alignment shift correctly when creating new vdevs on block
devices known to lie. The list of devices known to lie happened to
include the hardware used for benchmarking by Phoronix.

That being said, ZIL is the sole reason ZFS was able to perform as well
as it did once the alignment issue had been resolved. You can see this
for yourself by setting sync=always on ZFS. That will disable ZIL and
let you see how ZFS performs without it. It will not be pleasant.

> A number of people on the questions list have said that they find
> UFS+SU to be considerably less robust than the journalled filesystems
> of other OS's.

This is not a constructive criticism. First, it is not possible for a
filesystem developer to act without a description of the system, what
was running and what went wrong. Second, it is ambiguous. What does
"robust" even mean here? I can think of several possible meanings.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140314/5b870cc7/attachment.sig>