Your scenario will be slightly worse. To create a 2 TB volume, you have to use an 8 MB block size, 4 MB will only allow 1 TB. And yes, you will have to read bigger chunks of data to get what you want, so there is a bit of a performance hit, but the penalty is usually offset by the cache to have on your array. You will hit more of a penalty if you have multiple servers that need access to the same block, and so will wait until the first read is done before having access to it.
> what size is the block that will be read from SAN?
I've just done a copy of a folder tree between two VMDKs and checked the I/O sizes with the EVA's performance utility (EVAperf).
Sometimes I saw a few I/Os with transfer sizes larger than 512KB - most sizes are between 4KB and 128KB. I even saw sizes smaller than 4KB.
Honestly, that did not surprise me
Great answer bugcheck!! Last friday I called VMware Support to get some info on this. And they explained that the blocksize of the guest filesystem is the blocksize that will be read. The VMFS blocksize is not the blocksize that will be read from the SAN !!!!
The blocksize does has some impact when seeking begin and end of a block / chunk. That is what the partition alliging document refers to. Its about positioning the heads, NOT reading the blocks. So, if you have a NTFS file system in your guest, with only 32kb blocks, then 32kb blocks will be read from the SAN.