Absolutly. USB pen drivers have erase blocks as well. Trying to find them is hard though. I tried having no partition on them and just dumping an vfat filesystem on it, but the other OS didn’t agree. Ubuntu/linux worked just fine with it.

I went ahead and created a partition starting at 1024 (fdisk -u /dev/sdb) which should be okay.

If you are using it linux exclusive, or your other OS has no issues with un-partitioned disks, just don’t make a partition at all! if you use ext* you can specify a stride size still, I do think to have stride sizes for ext* makes them more efficient as bitmaps etc are on erase block sizes as well.

What I was thinking of was, getting the LBA (which is ‘physical’ enough) addresses of certain bits.
E.g. query your partition start’s LBA, say LBA 4, which would be an alignment of 1k (512 *4) (this being for demonstration purposes). Then, query your md start block somehow, let’s say this returns anything other than LBA 4 you are miss-aligned. Next query your FS start blok (or lvm) and same routine.
Then you know that your starting bits are all on the same blocks and thus physically aligned. Of course all other offsets need to match then, e.g. stride size etc etc.

Maybe it would be possible to write a few files starting with a known magic value and then get their position on the disk relative to the start of the file system, using fs-specific commands? Then one would check the disk on a physical level with “dd skip=$(calculated position of fs start + position of files IN the fs, rounded at 128k multiples)” trying to find those magic numbers. But this has several drawbacks: It assumes that the fs is contiguously allocated (no LVM!) and that the SSD itself starts with an aligned (=full) block (a safe assumption, i think) and also still requires some calculations. Also it would be fs-specific. But it could be automated.

Still, trying a few values and observing the impact on performance would probably be easier, although time-consuming. Performance is what we care about after all. However, performance differences could be VERY small, since generation 2 drives tend to be a bit too “smart”. Do you know any reliable and suitable benchmark? (Maybe bonnie++ ?)

The problem with that method is that performance differences could be negligible (and thus not enough to check the alignment), but the impact of misalignment on the drive wearing could still be very significant.

Oh well! I hope that my new, shiny SSD is smart enough by itself! Sorry for the bad English,
Nicholas K.

I’ve ordered an Intel G2 solid state drive and it should arrive in a few days, so in the meantime I decided to apply your instructions on a regular hard-drive and dd the result on the SSD once it arrives. However, I won’t be using LVM and this poses some problems. I’ve got two questions:
1) I used cfdisk and manually set ‘ -h 224 -s 56 ‘ but I had to create quite a few “logical” partitions. Doesn’t that screw up the alignment? According to Wikipedia the Extended Boot Record takes up some space…
http://en.wikipedia.org/wiki/Extended_boot_record
2) Is there any method to verify the alignment of the data of a data-filled, arbitrary partition regardless of the partitioning method used (MBR/GPT/LVM etc), at least when using ext3/ext4? (Without having to repartition or calculate by hand!) I’m thinking something like a benchmark-based program but it probably doesn’t exist yet (and it would probably require write access).

Thank you in advance. Greetings from Europe,
Nicholas K.

PS. Keep up your great kernel-hacking job!