Date: Fri, 14 Mar 2014 13:12:15 -0400 From: Richard Yao <ryao@gentoo.org> To: RW <rwmaillists@googlemail.com>, freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <5323386F.2020402@gentoo.org> In-Reply-To: <20140314152732.0f6fdb02@gumby.homeunix.com> References: <CAA3ZYrCPJ1AydSS9n4dDBMFjHh5Ug6WDvTzncTtTw4eYrmcywg@mail.gmail.com> <20140314152732.0f6fdb02@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/14/2014 11:27 AM, RW wrote: > On Thu, 13 Mar 2014 18:22:10 -0800 > Dieter BSD wrote: >=20 >> 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).=20 >=20 > NetBSD didn't simply drop soft-updates, they replaced it with > journalling, which is the approach used by practically all modern > filesystems.=20 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 i= n 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=3D27555= 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=3Dalways 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. --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIzhyAAoJECDuEZm+6ExkSf0QAKq3grWNulcuFl5Hh3gE2Udq AnomphSeiqs8ZNjylOF2PFPiirSHfexNfrKAqOGvJSGq4njJjFz6DMV412m0hSpl JZGv3yNgnS8bUZprcpun298OK9POSrgV/XmgtNmhYS3S14y1h1p+xPmdZYx/TwEi lA3i4Uns8mRxn/fZHh5sjqPdNEzgONj521nmEiW8TGuLc9giKyAGjKv++38W9upe DSPnl6zbj4Y9wy+q58T1lG0iMzgc+LHtHkwZn2bVSzQOoIwMdsd76lqf8L+kqJJ5 sirA+v0lwpd1ZpnehkWmV4fEVHBTEuMjnCcWGqA9kTg4Tnaa8jp9iZJ8GOX5zRgm /wMqMiWjCFLGkg4fTI6KLEZzisMDGbQwgS3tMbwAGZV0aa3p04027RYPqpUb6LJV +3dJjPnnVg69GLbAn479UHdlqZgaQA9BCo7Rv7Xp1VkNYnPYrdYSEfEhscvmsCif FJVImC2eJAozZU9IcHUAUQcerM1vgk8znj+oL3Tky8CvLHkbRsB/HidNeyIjc7Em e1EMi4Qhpl1eiyBw8Y7RZF2U0qwGBsz+MfxNi9ajxS7hkbEWR1qAhtChlju2TJ44 SBefupz/uEpMg2etK81UiRYIHtmdhcUn4HYoHrjh/aGFxoNP6Wx0HzuhiGte/tkr 05nc6pJP1d5wOZFFSOB6 =IXWF -----END PGP SIGNATURE----- --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5323386F.2020402>