On Tuesday 29 March 2011 20:26, Harald Becker wrote: > > 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.
How 1st "sync; sleep" helps in regard to "allow running processes finish normally"? I don't see it. Until you signal them with TERM, how do they even know they are supposed to stop (IOW: how do they know to stop generating more dirty filesystem data)? While 1st sync waits for write out to end, there is no telling how many more dirty data is being generated! You may end up writing out much more than if you didn't do this 1st wait. > 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. I don't like special-casing shutdown with the knowledge of "special" processes. > Other > heavily active processes, running in the back, shall usually get time to > finish before shutdown, IMHO. *All* processes should be given time to shut down. That's what you achieve with the sleep *after* killall5 -TERM. Sleep *before* it is pointless. > >> 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. Sounds like kernel bug to me. How many sync's do I need in general case? 2? 3? 33? > 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. sync thread releases CPU while it waits for writes to complete. Therefore CPU is available to any other threads, such as those loop device threads (actually I'm unsure kernel uses threds for loop devs, but let's assume it does). Therefore thread prio should not be relevant. > 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. And if I have loop device on a loop device on a loop device? > ... or call it experience, payed by lose of the work of three days :-( Sure. As I said, paranoia (IOW, defensive coding) is not a bad thing. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
