Re: fsync in glib/gio

["Brian J. Tarricone" <bjt23 cornell edu>]

On Sat, 14 Mar 2009 13:16:45 +0100 Alexander Larsson wrote:

> On Fri, 2009-03-13 at 14:34 -0700, Brian J. Tarricone wrote:
 
> I think you are conflating two issues.

No, I don't think I am.  I think I'm just replying to a subset of the
email that's slightly off topic.  Or rather, the fact that I'm only
replying to someone's assertion that the filesystem is broken and that
I was ignoring the issue of gio initially made my reply a bit off topic.

> 1) Should glib/gio fsync at least in the really bad data loss case to
> make sure users are not losing data on such filesystem

Right, I think we're in perfect agreement that this is a 'yes', though
we may not agree that gio should fsync quite as often (I'd advocate to
do it *only* in the rename-over-existing case, and to have the default
be no-fsync everywhere else).

> 2) such filesystems are broken
> 
> Clearly the answer to 1 is yes. Anything else would be a disservice to
> our users data. However, that doesn't mean such filesystems aren't
> broken, in the sense that I would never let a filesystem like that
> near any of my data.

Well, you're certainly entitled to your opinion.  Personally I don't
think the filesystem is broken.  It's behaving within spec.  You can
argue that the spec is broken, or that it specifies behavior that
defies common sense, but it's there, and it's been there for quite a
while, so I don't quite understand why this is suddenly such a big
deal.  (Well, sure I do: no one decided to use a FS that behaves like
this as a distro default before, I guess.)

This is, btw, why I wouldn't use XFS on a partition with data I care
about.  XFS was designed with priorities other than data integrity in
mind.  I accept that, use something else, and move on.  You don't see
anyone declaring XFS broken (well, at least, not anyone knowledgeable),
do you?  So why is ext4 broken?  Because it's being touted as an ext3
replacement, I guess...

> For instance, any script doing sed -i s/foo/bar/ file.conf on such a
> filesystem risks ending up with a zero byte file.conf. (sed uses
> rename but doesn't fsync.) Is this what users except? Should that
> script be rewritten in C so it can use fsync? Should sed fsync?

Yes, it should!  Given the spec, if it does anything less, it's
risking user data.

> That
> kind of reasoning will lead to all apps implementing fsync-on-close
> manually, and we're then worse off than if the fs just guaranteed
> data-before-metadata-on-rename.

Yep, probably true.  But the right move here is to get the spec
changed, not say "any filesystem that follows the spec but doesn't work
the way *I* think it should is broken."  How is that approach at all
useful in the big picture?

> > Yeah, I'd totally agree.  But in the absence of an ability to
> > change the spec, it's best to try to make things work as well as
> > they can within the spec, no?  It seems like some people are
> > advocating "well, today everyone uses ext3, and there's no problem,
> > so we shouldn't do this because it'll reduce performance there."
> > And of course, a year from now (or less!  obviously some already
> > are), I'm sure most desktop distros will be shipping with ext4
> > default.  (And I could be wrong, but it seems to me that ext3 is
> > the only FS that, by coincidence will usually be immune to this
> > problem, and, also coincidentally, is one of the only FSes that has
> > crappy fsync() performance.)
> 
> ext4 from the next kernel release will have patches that makes the
> rename case safe, although it will be an option that can be disabled.
> Not sure about btrfs. Its unsafe at the moment, but chris mason is
> talking about possible fixes in the lwn thread.

That sounds pretty awful, to me, to be honest.  So every FS -- no, wait
-- every FS that's going to be pushed as a "mainstream" FS -- is going
to have to be closely monitored to make sure it doesn't have this
behavior?  Everyone's going to be putting little band-aids over this
issue, but only in FSes we "care about?"  The underlying issue, the
root cause -- that the spec allows what many consider very unsafe
behavior -- is just going to be ignored?

Sigh.  Well, I guess I'm getting even more off topic here, so I give
up.  I see farther down in the replies Mark argues pretty much the same
thing I am, only doing a better job of it.

	-brian