On Tue, 2009-11-17 at 05:34 +0100, Goswin von Brederlow wrote: > Keld Jørn Simonsen <keld@xxxxxxxxxx> writes: > > > On Mon, Nov 16, 2009 at 04:26:32PM +0100, Goswin von Brederlow wrote: > >> Kasper Sandberg <postmaster@xxxxxxxxxxx> writes: > >> > >> > Hello. > >> > > >> > I've been wanting to create a raid10 array of two SSDs, and I am > >> > currently considering the layout. > >> > > >> > As i understand it, near layout is similar to raid1, and will only > >> > provide a speedup if theres 2 reads at the same time, not a single > >> > sequential read. > >> > > >> > so the choice is really between far and offset. As i see it, the > >> > difference is, that offset tries to reduce the seeking for writing > >> > compared to far, but that if you dont consider the seeking penalty, > >> > average sequential write speed across the entire array should be roughly > >> > the same with offset and far, with offset perhaps being a tad more > >> > "stable", is this a correct assumption? if it is, that would mean offset > >> > provides a higher "garantueed" speed than far, but with a lower maximum > >> > speed. > >> > > >> > mvh. > >> > Kasper Sandberg > >> > >> Doesn't offset have the copies of each stripe right next to each other > >> (just rotated). So writing one stripe would actualy write a 2 block > >> continous chunk per device. > >> > >> With far copies the stripes are far from each other and you get 2 > >> seperate continious chunks per device. > >> > >> What I'm aiming at is that offset might better fit into erase blocks, > >> cause less internal fragmentation on the disk and give better wear > >> leveling. Might improve speed and lifetime. But that is just a > >> thought. Maybe test and do ask Intel (or other vendors) about it. > > > > I think the caching of the file system levies out all of this, if we > > talk SSD. The presumption on this is that there is no rotational latency > > with SSD, and that no head movement. > > Filesystem has nothing to do with this. It caches the same for both > situations. The only change happens on the block layer. > > > The caching means that for writing, more buffers are chained together > > and can be written at once. For near, logical blocks 1-8 > > can be written to sector 0 of disk 1 in one go, and logical blocks > > 1-8 can be written to sector 0 of disk 2 in one go. > > Which is what I was saying. > > > For far it will be for disk 1: block 1, 3, 5, and 7 to sector 0, and > > block 2, 4, 6 and 8 to sector n/2 - n being the number of sectors on the > > diskpartition. For far and disk 2, it will be blocks 2, 4, 6 and 8 to > > sector 0, and blocks 1, 3, 5 and 7 to sector n/2. caching thus reduces > > seeking significantly, from once per block, to once per flushing of the > > cache (syncing). Similarily the cache also would almost eliminate > > seeking for the offset layout. > > There is no seeking (head movement) and no rotational latency > involved. That part is completly irelevant. > > The important part is that you now have 4 IO operations of half the > size comapred to the 2 IO operations of the offset case. The speed and > wear will depends on the quality of the SSD, how well it copes with > small IO. Very interresting, i have some older SSDs where they are slower when doing a SMALLER write, so in this case offset should be alot better. > > > but I would like to see some numbers on this, for SSD. > > Why don't you try it out and tell us what you find? > > I would be interested in this myself. I don't have an SSD yet but I'm > tempted to buy. When you test please also test random access. I would > guess that in any sequential test the amount of caching going on will > make all IO operations so big that no difference shows. > > > Best regards > > keld > > MfG > Goswin > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
