>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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
