> and they're honest about this just being about boot time.

reboot, not boot, boot was already a non-issue after booting into sh and removing most of the services.

The later posts deal with shutdown, mostly by removing sleeps... which are there to wait for lying hardware to finish flushing its caches. So some of TFA's fixes are really recipes for data corruption if you're not using a readonly FS (which TFA is, so it's no problem for his precise use-case).

Yeah, I was reading the bits where they disabled the sleep()s and I couldn't help but wonder how many evil little bugs and device problems those kludges covered up.

Hmmm. For hard disks, a call to fsync could be sufficient instead of the sleeps, no?

No. sync() is the system-wide fsync() so it makes no difference. The issue is that sync() tells the filesystem to flush its caches to storage, the FS tells storage to get everything in permanent storage and the storage device lies its pants off and says everything is stored as soon as it's hit the controller or the write cache.

It's not like the layers above can just go "nuh-uh, tell me when it's actually really written for real", if the storage device is going to lie it's going to lie every time.

The way the SCSI layer is implemented in Linux, fsync() (for that matter O_SYNC I/O) doesn't really flush data to the non-volatile platter on disk. Too much of a performance hit if it did that all the time.

http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-os...

No: http://brad.livejournal.com/2116715.html

That blog post is from 2005. There was a major rework of how the block layer handles flushes back around 2010 and I'm pretty sure the issue he was having with fsync not being reliable has been resolved.

To go into the details, essentially, its the AHCI-driver(SATA) that handles 2 use-cases differently.

The more common being the case where there is an additional VFS driver between the app attempting sync-I/O and the AHCI driver which simply issues an asynchronous I/O command to the disk and returns immediately. The new data is guaranteed to be on the HDD but NOT guaranteed to be written to the non-volatile platter of the HDD. Data is often still in the HDD internal-cache, waiting to be written to the disk platter.

The 2nd case (very rare) is when the application attempting sync-I/O opens the HDD in raw mode i.e. opens the block device directly(without any VFS layer in between) with O_SYNC. Now following each disk-write, the AHCI driver issues a CMD_FLUSH to ensure that even the HDD cache is immediately flushed to the platter. As this eliminates any chance for NCQ to kick in, the performance drops by an order of magnitude but data-integrity is ensured.

If boot time is an issue, TinyCoreLinux has some of the fastest boot times and runs completely out of RAM, runs on x86, x86_64, armv6 (Pi), armv7 (GK802, AllWinner A-10).

[1]http://tinycorelinux.net/

This guy has been doing some work on getting a raspberry Pi to boot fast: https://github.com/gamaral/rpi-buildroot

Demo: http://www.youtube.com/watch?v=4Fjfqz6FxC8 It seems to be 3 to 4 seconds.

It is however for a specific use and I don't know how polyvalent it is.

There's a great case study and documentation at eLinux.org.

This guy stripped a Renesas SH7724 boot-to-UI from 19.44 seconds down to 0.77.

http://elinux.org/images/f/f7/RightApproachMinimalBootTimes....

The tl;dr is that there's a lot in the kernel you can disable or strip away if your target system doesn't need it. The section on optimizing your application for block-oriented storage (like NOR flash) is a great one too.

Crowdfunded contest?

Kickstarter?