On a recent Linux distribution, the kernel should provide the physical sector size of the device and the partition/lvm/mkfs tools should automatically chose the alignment such that it is compatible with the physical sector size (for best performance).
For example on a Debian system of mine:
# cat /sys/block/sdb/queue/physical_block_size
4096
# cat /sys/block/sdb/queue/logical_block_size
512
Update:
To check for kernel support, you can check if /sys contains the mentioned files, you can call fdisk -l to check if it prints this information (it should), you can check the specification of your hard disk (available by your vendor), you can check the changelog and/or source of LVM tools. Most mkfs commands provide a verbose option to see what block size is used. Last but not least you can just do a simple benchmark - e.g. one without any LVM (e.g. whole disk as device) and repeat it when your LVM setup is in place.
It seems like you've got the right idea. I'm going to assume that this is a home PC with a small number of users...
It can be a good idea to start completely fresh user profiles, in which case, you may want to create new user accounts, each with the same names and UIDs. It'd be easiest just to mount your previous /home partition, in /etc/fstab though.
If you create new user profiles on the SSD, then all the user-specific configuration files will be on the SSD, so logging in will be SSD-quick. The whereabouts of your home folder shouldn't affect boot-time, but would have a slight impact on the time taken to log in.
As you quite rightly said, you'll want to keep the media directories (Downloads, Videos, Pictures, etc.) on your other partition(s). I've found a pretty reliable way of doing this is to just create sym-links from the old media directories to your new home folder. If you had to do this for lots of users, this would quickly get tedious, unless you wrote a wrapper script around useradd which creates the sym-links automatically.
In terms of what sized disk to purchase, how much space are you using on your root partition now?
df -h will show how much space is taken up by each partition. See this answer on askubuntu to get an idea of the space occupied by all installed packages.
If you'll be using dd, to duplicate your old root partition to the SSD, you'll need a new drive at least as big as the old partition. If you have hundreds of gigabytes of free space on your current root partition, you can shrink the partition using a tool like gparted, and that will allow you to copy the whole partition across, before expanding it to fill the drive.
SSD drives are ideally suited for swap space, but I've already got an old swap partition, so I just use that. I see swap space as only strictly necessary in memory-limited emergencies, which I suffer very little from. YMMV.
Easiest solution? I'd just move the / partition, and keep the rest as is. I find SSDs mainly flourish in terms of boot time and application startup time. With that in mind, you only really need /boot, /usr, /lib and /var on the SSD; everything else can be elsewhere, with minimal effect on system performance.
EDIT:
Another optimisation worth making on SSD drives is with the mount flags specified in /etc/fstab. From the Arch Wiki and forum, on an ext4 partition, you might add:
UUID=xxx-xxx-xxx / ext4 rw,discard,data=ordered,noatime 0 1
The discard flag turns on TRIM support in the firmware; data=ordered optimises journaling on supported file systems on SSDs; noatime turns off recording files' last access time.
Best Answer
Yes, it is true.
The platters in a disk rotate at a fixed speed (7200 RPM in the common case). As such when the head is over the outer portion of the platter more surface area passes under the head per rotation than on the inside track. Thus more IO per rotation is possible.
(The 'beginning' of the drive is the outside tracks of the platters)
Now whether this is going to be at all noticeable, especially for swap which you shouldnt be using extensively anyway, is debatable.