Hallo Denys! > Better approach is to parallelize initial sync and kill: > sync & > killall5 -TERM > sync; sleep 1.5s > > Otherwise the "sync; sleep 0.25s" line may end up waiting > for a very long time if you have tons of dirty data in RAM.
It is in fact a nice approach to parallelize a sync, but that depends on how and what things you are trying to achieve. That initial sync/sleep may be heavily understood and is a bit tricky. It solves some problems I noted during shutdown in an easy fashion, most likely such problems are solved in shutdown scripts using complex technics. That first sync is indeed a variable delay and you are right it may delay for a long time if you run an I/O intensive process, but that delay is intentional. There you need to chose which task has priority, shutdown or let running running processes finish normally. To avoid extreme unwanted delays at this, I always send long running and disk intensive processes a specific termination signal before stepping in the final shutdown routine. Other heavily active processes, running in the back, shall usually get time to finish before shutdown, IMHO. ... but otherwise it depends on the admins choice. >> sync; sleep 0.25s >> sync; sleep 0.5s > Double sync is not needed, but you might want to have it > simply because of paranoid reasons > (every good admin should be a bit paranoid) :D Denys, you fail at this. It's not only paranoia. If I leave out that second sync on my SSD, there is a high probability that fsck complains for an unclean unmount on next startup ... and that problem only vanishes if I use high delays for the sleep (5s or above). So I looked a bit deeper at it and found the following: Consider loop devices mounted on files sitting on the SSD. The umount tries to shutdown those devices, but may delay this due to the "-l" lazy option. So the first sync may flush the remaining buffers that allow to finish the loop device shutdown. That shutdown seems to happen after the sync finishes ... but indeed leaves some unflushed buffers on the master device in memory which block the final unmount finishing of that device. The second sync now flushes out those buffers and finalize unmounting. I think the reason for this is, that loop devices are kernel threads. The sync thread seems to run at a higher priority as those loop device threads, hence they can't run/close before sync finishes. The loop device thread shutdown produces additional I/O on master device, which need additional flushing. That final flushing is fast on hard disks and done very quickly within the final sleep period but flash devices are different, they are slow on writing and delay that writing as much as possible, until it is forced with a sync (a second sync in that case). ... hence you need dual final sync to do a clean shutdown. ... or call it experience, payed by lose of the work of three days :-( -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
