lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toke Eskildsen>
Subject Re: SSD Experience (on developer machine)
Date Tue, 23 Aug 2011 13:05:34 GMT
On Tue, 2011-08-23 at 14:07 +0200, Marvin Humphrey wrote:
> I'm a little confused.  What do you mean by a "full to-hardware flush"
> and how is that different from the sync()/fsync() calls that Lucene
> makes by default on each IndexWriter commit()?  

A standard flush from the operating system flushes all OS write caches
to storage. That does not guarantee that the storage hardware has
flushed to persistent storage - it can still be in RAM on the device.
If the operating system flushes 1000 times/second, the SSD might still
only perform a single write to a solid state cell.

Now, running an important database with a lot of small updates, the "not
sure if it is really written"-approach might not be what the admin
wants. Disabling the on-SSD write cache ensures that all writes are
flushed. Since SSDs writes in blocks and not individual bits, this means
that a block will be written for each write from the OS. Couple that
with thousands of writes/second and the expected life of the SSD drops

(one obvious solution to me is to buy a SSD with a battery that
guarantees that the SSD-cache can be flushed in case of power failure,
but then again I am not a database admin so there might be problems with
this approach)

All of this is not a problem when building Lucene indexes. It is just a
standard flush and even if the SSD disk cache is disabled, we're talking
about "real" updates with substantial data, not just single bits
flipping, so the wear on the cells will be in the same ballpark as
standard SSD use.

NB: Sorry about the private email at first. I pressed the wrong button.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message