On 1/22/2014 11:22 AM, Bob Proulx wrote: > Another thing that I did was to install 'eatmydata' in order to use > the LD_PRELOAD library to disable fsync(). A lot of applications have > added fsync() calls everywhere to disable the file system buffer > cache.
fsync() doesn't disable the buffer cache but bypasses it for a given write. > I wanted to minimize writes to the SD card. Applications that > use fsync() are forcing writes through the cache to storage. This To make sure data is on disk before power fails, or the system crashes, etc. fsync() is a good thing. > does two bad things. Defeating the cache is many times slower. Quality, mature filesystems use fsync() only for journal and metadata writes, not data, to keep the filesystem in a consistent state after mishaps. Thus speed is application or workload dependent. An MTA workload using maildir mailbox format will take a hit as it is metadata heavy. A MythTV server won't notice the difference as there is nearly zero metadata in the workload. > Defeating the cache causes a lot of I/O for flash storage. This is patently false. fsync() causes no additional write IO. It simply commits "right now". Buffer cache simply delays the writes. The SD flash will see the same total number of writes regardless. > Both > things are undesirable with slower flash storage such as SD cards. Disabling fsync() and its cousins may improve performance with some workloads but it will not change flash cell life. > I think disabling fsync() had more positive performance effect than > tweaking vm.dirty_ratio. Both had strong positive effects for my > system load case. Other cases will be uniquely different. YMMV. If you are using EXT3 with its insane "journal everything" mode, then yes, this would yield a big boost. If you're using XFS, it shouldn't make a huge difference, unless of course your workload is all metadata. Disabling fsync() in this manner is a very bad idea because it removes the safety features built into filesystems. If your UPS fails, the kernel crashes, etc, you will likely have a corrupt filesystem. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e08b74.4000...@hardwarefreak.com
