[PATCH] fsync applet

[Cathey, Jim]

>I was asking why you need -f to indicate you're supplying a command
line 
>argument when you could list files on the command line directly, since
the 
>current command doesn't take any.

Ah, I see.  I suppose it was so that the original behavior
of sync(1) ignoring arguments was preserved, since the -f was
bolted on later?  Rationale lost in the dim past, but yes
the "-f" flag itself is semantically null as it was used
there.  That system had no fsync(), but it did have an
ioctl() that did the same thing.  I'm not sure if anybody
ever used it, the documentation was poor enough that it's
possible that nobody who could have used it really knew that
it was there.

>Yes I've timed it and it's waited longer than 15 minutes.
>Yes, the processes will be stuck in D 
>state and unkillable until the backup completes.

That's some seriously broken stuff there.  That old system
_never_ did anything like that, whether backing up through
the filesystem or whether attaching a drive mirror.  (The
initial cut of the SCSI spin-up/down logic would induce
non-device-related delays, but I fixed that in an afternoon
by putting in 7 semaphores where they'd used one.  That was
only about a 10-second delay, which was infuriating enough.)

And yes, I agree with you.  Though systems are a lot faster
now the loads put upon them are also a lot heavier.  Much like
the constancy of human behavior, the delays in systems tend to
hover at about what we will tolerate.  Twenty years ago's ten-second
delay is still today's ten-second delay.  Unless it's twenty.
Or five.  Never 0.01, which is what it would be based on clock
rates.

>It [fsync] also might let you know if there was an error, although it
just 
>flushes the file contents and not the metadata so you have to open the
>directory containing it and fsync that too if you really care.

I thought that was what fdatasync() was for, to avoid flushing
the metadata that fsync() is supposed to flush, if you don't need
it pushed out too.

>Plus the way cacheing works it doesn't usually try to write your
>data to disk until after you call close() so historically real physical
>disk errors happened when nobody was 
>listening, so the lower layers weren't very good about propogating them
up >and they just wound up in dmesg instead...

Broken is as broken does.  The whole point of fsync was to close
the loop all the way to the medium, was it not?  Hidden layers of
caching negate much of the purpose.

I guess I was only bringing up that old sync -f because what it
did was _different_ than an fsync(2) utility (by whatever name),
and arguably slightly useful.

-- Jim