Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Sat, 2009-03-14 at 14:30 -0700, Brian J. Tarricone wrote:

> > 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.)

All filesystems, including ext2 which may lose all filesystem data in
the case of a crash, are "behaving within spec". Any guarantee beyond
this is a quality/robustness of implementation issue in the particular
filesystem in use. Now, people did not think the robustness of ext2 was
enough, so ext3 added journaling. 

The commonly used idiom of write-to-tempfile-then-rename-over-target is
atomic as per POSIX spec (i.e. when the system doesn't crash, as that is
outside the spec), in that any app opening the file at any time gets
either the full old data or the full new data.

Now, a *good* (i.e. not only correct) filesystem should imho carry over
this property to a system-crash level. I understand that this is not
required by any document, and that it might cause some performance
overhead, but that same is true of e.g. journaling in the first place.
If we're merely going after the minimum requirements per the spec, why
even add journaling?

> 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?

Well, ideally there should be a way to say you need data-before-metadata
guarantees so that you don't have to force a fsync. However, I don't see
that happening really.