[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Install Debian on SD



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


Reply to: