SSD, XFS, LVM, fsync, write cache, barrier and lost transactions

We finally managed to get Intel X25-E SSD drive into our lab. I attached it to our Dell PowerEdge R900. The story making it running is worth separate mentioning - along with Intel X25-E I got HighPoint 2300 controller and CentOS 5.2 just could not start with two RAID controllers (Perc/6i and HighPoint 2300). The problem was solved by installing Ubuntu 8.10 which is currently running all this system. Originally I wanted to publish some nice benchmarks where InnoDB on SSD outperforms RAID 10, but recently I faced issue which can make previous results inconsistent.

In short words using Intel SSD X25-E card with enabled write-cache (which is default and most performance mode) does not warranty storing all InnoDB transactions on permanent storage.
I am having some déjà vu here, as Peter was rolling this 5 years ago http://lkml.org/lkml/2004/3/17/188 regarding regular IDE disks, and I did not expect this question poping up again.

Long story is:
I started with puting XFS on SSD and running very primitive test with INSERT INTO fs VALUES(0) into auto-increment field into InnoDB table. InnoDB parameters are

    

  1. innodb_buffer_pool_size=3G
    2. 

  2. innodb_data_file_path=ibdata1:10M:autoextend
    3. 

  3. innodb_file_per_table=1
    4. 

  4. innodb_log_buffer_size=8M
    5. 

  5. innodb_log_files_in_group=2
    6. 

  6. innodb_log_file_size=256M
    7. 

  7. innodb_thread_concurrency=0
    8. 

  8. innodb_flush_log_at_trx_commit=1
    9. 

  9. innodb_flush_method             = O_DIRECT
    10.

Actually most interesting one are innodb_flush_log_at_trx_commit=1 and innodb_flush_method = O_DIRECT (I tried also default innodb_flush_method, with the same result), using innodb_flush_log_at_trx_commit=1 I expect to have all committed transactions even in case of system failure.



( Read more )