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 drastically. (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: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
