SSDs are using a spare section of some gigabyte to continuesly change the place where blocks are written to. This spare area can be used to rotate the written blocks, even if the device is nearly full, isn't it?

Questions:
1) Does an SSD use free space inside a partition, too, to rotate the written blocks? Or is it just using the spare area for this? Is the spare area used across all partitions?

2) If one partition is nearly full, but another partition has many gigabytes free, can this free space be used to rotate the written blocks on the nearly full partition, too? This would mean that it is not important to have much free space on each partition, but only that the whole SSD requires free space summarized.

3) Should a swap partition better be placed on the SSD or on a normal hard disc drive?

4) If swap goes to SSD, how big should the parition be made? The same as on hard drives (Size of RAM + 30% for hibernation) or should it be much bigger to make shure that on hibernation not always the same blocks are used on the SSD?

SSDs are using a spare section of some gigabyte to continuesly change the place where blocks are written to. This spare area can be used to rotate the written blocks, even if the device is nearly full, isn't it?

yes.

Quote:

1) Does an SSD use free space inside a partition, too, to rotate the written blocks? Or is it just using the spare area for this? Is the spare area used across all partitions?
not free space on a partition, but unpartitioned space. this is called over-provisioning.

Quote:

2) If one partition is nearly full, but another partition has many gigabytes free, can this free space be used to rotate the written blocks on the nearly full partition, too? This would mean that it is not important to have much free space on each partition, but only that the whole SSD requires free space summarized.

no.

Quote:

3) Should a swap partition better be placed on the SSD or on a normal hard disc drive?

i would put swap outside the SSD

Quote:

5) Which file system should be used on a SSD? Just the normal ext4fs?

from todays usable and reliable filesystems only ext4 knows how to handle trim and discard. the upcoming btrfs does also.

So in conclusion (to make sure I understand it right) only the spare area is used to rotate the write operations.

no, as i said, you can use over-provisioning, which has, if you believe Intels numbers, brought up to 90% more iops in certain cases. 10% over-provisioning is supposed to bring longer live to your nand chipos as well.

Quote:

Background: Someone told me that there should always be about 40% of a partition be left free to make sure the write operations can still be rotated. So this seems not to be necessary?

Thanks, dibl, for the FAQ-Link. I had to read about the meaning of "over-provisioning". As I understand now, first the drive does this automatically by bringing the internal spare area, second I can do this manually by just creating a small partition that I do not use, so that the space will always be kept free, to enlarge the spare area (or at least reaching the same effect as with the spare area).

I have ordered a Corsair Force F115 with 115GB. I hope it is not a bad drive. All bigger ones that I could choose from were much more expensive. The OCZ Vertex3 120GB was +80EUR.

So together with the 5% reserve of ext4fs I could create an empty 5 or 10GB partition for over-provisioning.

devil, why would you not place the swap onto the SSD? I do not think that I will need much swapping (with 8GB RAM), but for suspend-to-disk it could be interesting to have fast data transfer. (I never had a PC with working hibernation, so I do not know how important a fast hard drive is for this).

Given today's SSD sizes, GPT is not important there (however gdisk handles a number of alignment issues on its own, something many other partition programs neglect).

GPT becomes mandatory for disks >= 2TiB (not the drives marketed with 2 TB, those are slightly below 2 TiB, but those starting at 2.5 TB), however when dual-booting with windows (vista sp2/ windows 7 only, vista gold or XP can't deal with GPT) is required, the windows installation routine only allows GPT from UEFI mode (right now we support gpt+bios, but not gpt+uefi, yet) - which, at this very moment, makes dual booting from GPT partitioned media 'impossible'; this does not affect mere data drives, which are not needed for booting.

Especially for a SSD, which is very likely to be the boot drive and right now only available in sizes far below 2 TiB, I strongly suggest to stick to a classic "MSDOS partition table" rather than GPT for the time being. UEFI and GPT are certainly gaining importance, but right now with early (and fragile) support for them in mainboard and OS implementations they create far more problems than they plan to solve (at least for booting) - if you can avoid it (boot disk < 2 TiB).