O_PONIES

Posted Jul 2, 2009 23:36 UTC (Thu) by mikov (guest, #33179)
In reply to: O_PONIES by mjg59
Parent article: In brief

Yes, but this is a problem in ext3 not in the syscall. It seems like a horrible idea to address problems in one file-system implementation by adding new Linux specific behavior to existing syscalls.

Adding transaction semantics to the file system in this one case is the road to madness. Fortunately I think that it has very little chance of being accepted in the kernel.

(Also, you can see my other response to spitzak below).

O_PONIES

Posted Jul 2, 2009 23:40 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

Look at it from the application programmer's perspective. There's no way to tell the difference between ext3 and ext4 - they return the same magic number in the statfs call. So an application can't decide whether to use fsync() or not at runtime. Given that applications have to run well on ext3, fsync() is simply not an option. Unfortunate, but there you go.

O_PONIES

Posted Jul 2, 2009 23:57 UTC (Thu) by mikov (guest, #33179) [Link] (1 responses)

Alas, I think there is probably no easy and beautiful solution to this one, especially from the application programmer's perspective. I wouldn't advice on relying on Linux specific behavior, which at that will presumably be available only in newest kernels, for such a basic task.

Instead I would suggest one of:

- Put all the error prone logic (the temporary file, fsync(), permission and attribute copying, etc) in a portable library routine relying only on POSIX and simply live with the fsync() overhead on ext3.

- Again put it in a portable library routine, but without the fsync(). The rename problem has already been addressed in ext4, so it is safe, and in ext3 there is a global sync frequently enough that it isn't a problem in practice (explaining why nobody ever complained about it before ext4).

O_PONIES

Posted Jul 3, 2009 0:19 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Right. My personal opinion is that Linux filesystems should be expected to behave atomically here - POSIX is a set of baselevel functionality, not an excuse for doing something that breaks applications. If people want portability to platforms that don't make these guarantees then they'll have to make some kind of sacrifice. I don't see adding extra flags as the best way of handling this.

O_PONIES

Posted Jul 3, 2009 16:55 UTC (Fri) by quotemstr (subscriber, #45331) [Link]

I'm firmly in the fsync-is-horrible-renames-should-be-write-barriers camp, but if you want to expose a way to for an application to tell whether it should fsync or not, the best way is to use the existing pathconf mechanism. Using that, an application can just ask the kernel, "Do I need to fsync this particular file?". It's much more elegant than trying to have applications puzzle it out from filesystem-type information.