Comments on: Rethinking B-tree block sizes on SSDs

By: Iosif

Iosif — Sun, 11 Oct 2009 16:12:37 +0000

Hi. I’m great follower of http://www.defmacro.org/ and just found this blog.

Maybe you are interested on this:
http://www.igvita.com/2009/02/13/tokyo-cabinet-beyond-key-value-store/

Bye,
Iosif.

By: Daily Links #109 | CloudKnow

Daily Links #109 | CloudKnow — Thu, 08 Oct 2009 16:40:44 +0000

[...] RethinkDB: Rethinking B-tree block sizes on SSDs [...]

By: RethinkDB - The database for solid state drives.

RethinkDB - The database for solid state drives. — Thu, 08 Oct 2009 11:44:18 +0000

[...] Rethinking B-tree block sizes on SSDs [...]

By: Slava

Slava — Thu, 08 Oct 2009 09:03:23 +0000

We did much more alignment related testing. I’ll post the results soon, but in general they’re consistent with these numbers. It might be that the SUPER TALENT MasterDrive OCX we’re testing on behaves differently from other drives. We’ll retest on Intel drives soon.

By: Colin Percival

Colin Percival — Wed, 07 Oct 2009 05:43:04 +0000

Looking closely at those performance numbers, I think glugglug may be right — either you’re making unaligned requests, or the disk is optimized for unaligned requests. I’m getting a very strong fit to a model with 16 kiB internal blocks and a shuffling cost for misaligned reads.

Could you measure E(time to read 16 kiB from offset (16 kB) * A + B for random positive integer A) for B = 0, 0.5 kiB, 1 kiB, … 15.5 kiB? Mean and standard deviation would both be useful.

By: Slava

Slava — Tue, 06 Oct 2009 22:15:06 +0000

gugglug: all tests were performed on the raw block device, so I don’t think they’re affected by partitioning artifacts. In this context we only tested reads, so the 128KB erase cycles aren’t relevant either. It’s very difficult to obtain information on what happens within the drives themselves, so unfortunately we have to resort to building up models of how they operate based on extensive testing. We’re talking with a couple of manufacturers, so hopefully we’ll have more definitive information soon.

By: originalgeek

originalgeek — Tue, 06 Oct 2009 21:01:06 +0000

Hey glugglug, this test and analysis has nothing to do with disk formatting. It has to do with the choice of page size for storing btree indices. This is a variable chosen by the database server, and is independent of the cluster size on the disk.
Admin: Edited to tone down a little.

By: glugglug

glugglug — Tue, 06 Oct 2009 20:52:39 +0000

Your graph of the SSD performance reflects non-optimal partitioning.

Every modern OS uses a cluster size that is a multiple of 4KB, so in theory there shouldn’t be a difference in IOPS between a 512B write and a 4KB write.

SSDs also have internal clusters that are multiples of 4KB, and the blocks that get erased for read/erase/write cycles are at least 128KB. But for the sake of backwards compatibility, 512B sectors are still emulated.

Unfortunately, most partitioning tools still start the 1st partition on sector 63 (counting 512B sectors), which is not a multiple of 8 to have it 4KB aligned. If you partition using Windows 7 or other smarter tool to keep your partitions 4KB aligned, you will not see a difference in IOPS between 512B operations and 4KB operations. (and since 4KB will be higher, the dropoff afterwards will be steeper).

By: Gregory Gross

Gregory Gross — Tue, 06 Oct 2009 18:53:19 +0000

Thanks for the write-up. Very informative.