The Transcend TS256GSSD720 erase block size and write block size

From OCZ's "The ABC Guide" to SSD's regarding alignment:

Default Vista and Win 7 create aligned partitions at an offset of 1024KiB.

[...]

Mac OSX Disk Utility aligns partitions in HFS+. As do most newer distros of GNU/Linux.

However, as you mentioned, the Vertex 3 has an erase block size of 2MB, which is not a factor of the current alignment offset; for this reason, I would indeed recommend moving the alignment to 2MB. From the OCZ forums, here's a guide on how to use gparted to align a SSD. There is also this tool for Linux to manually align a solid state drive.

I'm not 100% sure but have been looking into the same question. I believe that it can have an effect but depends also on the physical and logical block sizes reported by the disk. If so, it would affect both performance and durability.

The filesystem block size is the smallest addressable unit for the filesystem. Filesystem requests are passed to the device driver to get the data from the disk. The device driver will convert into device block requests based on the logical/physical block sizes of the disk. On Linux you can see e.g. /sys/block/sda/queue/logical_block_size and /sys/block/sda/queue/physical_block_size.

If the device block size is lower than the page size of the device then the requests will anyway be broken down further no matter how large they are to start with. This seems like suboptimal behaviour anyway that should be fixed first - I think it is not uncommon to see 512B on a modern SSD with 4/8KiB pages. See Changing sector size on Samsung 840 SSDs.

If the device block size is the same as the page size, say 8KiB, then it seems likely that two 4KiB requests from filesystem would result in a unnecessary second request and in the case of writes especially this would be pretty bad.

What is not clear to me is the extent to which either of these effects is mitigated by controller or OS caching. jon's answer does not provide much detail or evidence. It sounds pretty likely that reads would be cached, as this would anyway be a risk-free performance and durability optimisation. Write-caching is normally enabled for SSDs too but is optional. It then depends a bit on the cache policy/flush interval. On Windows there seems to be some confusion around write caching options (the accepted answer to What does "Write cache buffer flushing" mean doesn't really explain the difference between two settings and other articles also conflate them).