Date: Fri, 14 Mar 2014 14:53:08 -0400 From: Richard Yao <ryao@gentoo.org> To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, RW <rwmaillists@googlemail.com> Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <53235014.1040003@gentoo.org> In-Reply-To: <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> References: <CAA3ZYrCPJ1AydSS9n4dDBMFjHh5Ug6WDvTzncTtTw4eYrmcywg@mail.gmail.com> <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On 03/14/2014 02:36 PM, Edward Tomasz Napiera=B3a wrote: > Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 14 mar 2014, o godz. 16:= 39: >> On Fri, 2014-03-14 at 15:27 +0000, 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).=20 >>> >>> NetBSD didn't simply drop soft-updates, they replaced it with >>> journalling, which is the approach used by practically all modern >>> filesystems.=20 >>> >>> 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. =20 >=20 > Let me remind you that some other OS-es had problems such as truncation= > of files which were _not_ written (XFS), silently corrupting metadata w= hen > there were too many files in a single directory (ext3), and panicing in= stead > of returning ENOSPC (btrfs). ;-> Lets be clear that such problems live between the VFS and block layer and therefore are isolated to specific filesystems. Such problems disappear when using ZFS. >> What I've seen claimed is that UFS+SUJ is less robust. That's a very >> different thing than UFS+SU. Journaling was nailed onto the side of U= FS >> +SU as an afterthought, and it shows. >=20 > Not really - it was developed rather recently, and with filesystems it = usually > shows, but it's not "nailed onto the side": it complements SU operation= > by journalling the few things which SU doesn't really handle and which > used to require background fsck. >=20 > One problem with SU is that it depends on hardware not lying about > write completion. Journalling filesystems usually just issue flushes > instead. This point about write completion being done on unflushed data and no flushes being done could explain the disconnect between RW's statements and what Soft Updates should accomplish. However, it does not change my assertion that placing UFS SU on a ZFS zvol will avoid such failure modes. In ZFS, we have a two stage transaction commit that issues a flush at each stage to ensure that data goes to disk, no matter what the drive reported. Unless the hardware disobeys flushes, the second stage cannot happen if the first stage does not complete and if the second stage does not complete, all changes are ignored. What keeps soft updates from issuing a flush following write completion? If there are no pending writes, it is a noop. If the hardware lies, then this will force the write. The internal dependency tracking mechanisms in Soft Updates should make figuring out when a flush needs to be issued should hardware have lied about completion rather simple. At a high level, what needs to be done is to batch the things that can be done simultaneously and separate those that cannot by flushes. If such behavior is implemented, it should have a mount option for toggling it. It simply is not needed on well behaved devices, such as ZFS zvols. --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8 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/ iQIcBAEBAgAGBQJTI1AWAAoJECDuEZm+6ExkY5UP/2fOF5OYHwbKrUbqYxUpnpD1 +rj7HUwVVrY9ebx2KNJkQmOfMKN7r+GUlk3pBq3rupevhjWuTCVLDaRxKXxRb+LY u7tHfBPiEHVV4Zhq1C/V+XEIJsq91DsEUtMXUxUZkSA3uYf1ifzXNxUvEaT9UIsF hHm3Ud7j4bCz3VCVdaOGMpfPJ7pd9vCn0pjo1CS66MH/JVyd5zUD57F1Z7oaDDP5 KV9QEUR9V3CDoasqHtIcQweUpaRfWskiEBFBWpBN4vhJ2qR8UBmEobI886Foe8Yf XNv0ybXIOqzpoG0LXhHy2tEA9p7whs+slI++EPM2R9IrfL7Zv3AizNWCkXEZDx/r zGwyYWboCsKYoE4Hj8rx69s+A5K02ea4xVh9wE8EEEMwapyvVxx3X5XyZbPn6zQw C8HA1kvt8PL0BDObFUYq57GM6aUiqBPEHdXkhwbt7TDsO4qiVk9YpkCe5teToXP2 Oe1sEWb4VFcfZoUNlJc725PCNq/nBw00+jVAufN8+aX3HH+xxwHLxTW5ktn+I9vY tlCMhl3iOjOpIwZlos+pg7XKRUDmkEEZ0o/quDRlazyYH5wAz9Tk92aMlXjDRNpR BgzPTMn9oVUq+kK+zivWktpM4NBLFa+4RQAEjNxkIIt9tiCa4T9qOd1SmB4FMDqu V28bIayJU83sp/9ams1+ =qwHw -----END PGP SIGNATURE----- --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53235014.1040003>