Date: Fri, 14 Mar 2014 20:18:50 +0100 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org> To: Richard Yao <ryao@gentoo.org> Cc: freebsd-hackers@FreeBSD.org, RW <rwmaillists@googlemail.com>, Ian Lepore <ian@FreeBSD.org> Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <9DA009CD-0629-4402-A2A0-0A6BDE1E86FD@FreeBSD.org> In-Reply-To: <53235014.1040003@gentoo.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> <53235014.1040003@gentoo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomo=B6=E6 napisana przez Richard Yao w dniu 14 mar 2014, o godz. = 19:53: > 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: >>>>=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. >>>>>=20 >>>>> 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 >>>>=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 = when >> there were too many files in a single directory (ext3), and panicing = instead >> of returning ENOSPC (btrfs). ;-> >=20 > 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. Such problems disappear after fixing bugs that caused them. Just like with ZFS - some people _have_ lost zpools in the past. >>> 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 = UFS >>> +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. >=20 > 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. Assuming everything between UFS and ZFS below behaves correctly. > 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. >=20 > 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. As you say, it's not needed on well-behaved devices. While it could help with crappy hardware, I think it would be either very complicated (batching, as described), or would perform very poorly. To be honest, I wonder how many problems could be avoided by disabling write cache by default. With NCQ it shouldn't cause performance problems, right?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DA009CD-0629-4402-A2A0-0A6BDE1E86FD>