> > A lot of applications always rely on their file i/o being done in some
> > manner that has atomic (from the application's point of view) operations
> > other than system calls -- heck, even make(1) does that.
>
> Nobody is forcing you to hit the power switch in the middle of a build.
> But now that you mention it, you've provided a good example of a broken
> application. Make with its reliance on timestamps for determining build
> status is both painfully slow and unreliable.
Actually I mean its reliance on files being deleted if the problem or
SIGTERM happened in the middle of build ing them.
> What happens if you
> adjust your system clock?
Don't adjust the system clock in the middle of the build. Adjusting
clock backward for more than a second is much more rare operation than a
shutdown.
> That said, Tux2 can preserve the per-write
> atomicity quite easily, or better, make could take advantage of the new
> journal-oriented transaction api that's being cooked up and specify its
> requirement for atomicity in a precise way.
I have already said that programs don't use syscalls as the only atomic
operations on files -- yes, it may be a good idea to add transactions API
on the top of this (and it will have a lot of uses), but then it should be
made in a way that its use will be easy to add to existing applications.
> Do you have any other examples of programs that would be hurt by sudden
> termination? Certainly we'd consider a desktop gui broken if it failed
> to come up again just because you bailed out with the power switch
> instead of logging out nicely.
Any application that writes multiple times over the same files and has
any data consistency requirements beyond the piece of data in the chunk
sent in one write().
-- Alex---------------------------------------------------------------------- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/