I've never seen NAND erase blocks of fractional MB, 1536 is 1.5MiB. This means that you have to go 3MiB to keep erase blocks aligned, but really, if you get page size alignment right, this isn't that great a deal. This isn't as bad as getting page alignment wrong, this will cause a lot of extra writes.

Getting erase blocks misaligned will also cause premature writes but it won't happen as often and on good disks, garbage collection will happen in the background anyway.

So if you want, make sure your MB boundaries are on 3MiB boundaries, but it's not that big a deal. Just don't align by sector (512B) - that will kill performance if you're off by 1. Off by 0.5 MiB or 1MiB, you won't notice._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

Thats the first information you'll need: the logical sector size is 512 bytes.
When deviding the erase block size (1536 * 1024 bytes) by the logical sector size (512 bytes) you'll get 3072 sectors.
Lets go back to gdisk. In the expert options (x) You can edit the sector alignment value (l).
Set this to 3072, like calculated above. After this return to the gdisk main menu (m).

BIOS booting from a GPT works here. There is a trap or two for the unwary.

First, your GPT disc must have a valid protective MSDOS partition table.
It needs the signature word at the end correct and at least one partition defined.
The boot loader needs to be in LBA 0, grub-legacy works for me.

Lastly, some brain dead BIOSes will check the bootable flag. To keep these BIOSes happy, this needs to be set on the one partition in the protective MSDOS partition table, not on the real GPT boot partition.

The last trap for the unwary is that on a GPT drive, grub cannot install its stage1.5 file, as there is no space. As a result, stage1 blindly loads stage2 using a block list.
This means that if grub-legacy is ever updated, it must be reinstalled to the MBR to update the block list.

Be aware that many SSDs lie about the sector size. They are never really 512B but the drive will do read/modify/writes to fake this for the operating system._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Its safe to assume that the erase block size is exactly divisible by the physical write bloc size, whatever that may be so if you want erase block alignment, use a tool that understands partition sizes in Mb.

The hard bit is moving the start of the first partition around.
However, an others have said, write block alignment is much more important than erase block alignment._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

to get the correct alignment, the initial sector of each partition must be a multiple of 1536kb, according to this table

Size Sectors
512 bytes 1
1 kb 2
512 kb 1024
1 MB 2048
1 GB 2097152

the minimum would be 3072 sectors.

link for the table and further explanation.
http://siduction.org/index.php?module=news&func=display&sid=78

Edit 21/05/14
New source confirming 1536 kiB EBS and 8 kiB page size.

https://bbs.archlinux.org/viewtopic.php?pid=1385980#p1385980

---------------------------------------------------
Information about optimizing ext4 filesytem
----------------
to create the FS, ext4, we will take into account once again the Erase block size,

According to the recommendations here
http://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/
https://raid.wiki.kernel.org/index.php/RAID_setup#ext2.2C_ext3.2C_and_ext4

If the chunk-size is 128 kB, it means, that 128 kB of consecutive data will reside on one disk. If we want to build an ext2 filesystem with 4 kB block-size, we realize that there will be 32 filesystem blocks in one array chunk.
stripe-width=64 is calculated by multiplying the stride=32 value with the number of data disks in the array.
A raid5 with n disks has n-1 data disks, one being reserved for parity. (Note: the mke2fs man page incorrectly states n+1; this is a known bug in the man-page docs that is now fixed.) A raid10 (1+0) with n disks is actually a raid 0 of n/2 raid1 subarrays with 2 disks each.

We'll use the setup of a "raid" with a single drive, making the chunk size equal to the EBS, and using the usual 4KB block size.

I have the same SSD and following these steps aligning has been OK for me.

Code:

# blockdev --getalignoff /dev/sda6
0

I'm not sure where this blockdev --getalignoff advice is coming from. For most disks it will return 0 for almost anything. There is no magic, the system does not know the SSD page size, so it can't tell you anything about alignment.

Erase block alignment does not matter much at all, reads and writes are aligned to page size, not erase block size. The addressing is remapped inside the SSD anyway.

Reads are aligned on page size
Writes are aligned on page size
To ensure that logical writes are truly aligned to the physical memory, you must align the partition to the NAND-flash page size of the drive.

An 1.5MiB alignment (on the filesystem level) is impossible anyway. Especially in Gentoo. Too many small files (>50k for a single /usr/src/linux Kernel). If you line these files up with 1.5MiB alignment for each individual file, it would waste 50k erase blocks and consume 75GiB. I sincerely hope that the SSD will do better than that.

In general my experience with SSD so far is that they "just work", and work well, without any special considerations. Don't worry so much about alignment and write cycles. MiB alignment you get pretty much automatically (any tool does that nowadays, mdadm / cryptsetup / lvm etc. all changed their defaults in that regard if it wasn't already MiB aligned before). Add a weekly or monthly fstrim to that and you're good.

From an Arch linux forum guy who suggests for SSD Samsung 840 EVO 250 GB partitioning be done in this way:
How to correctly partition and create ext4 fs on this SSD, taking care of the alignment based on Erase Block Size and Page Size.

Wicked man I've been searching for this all afternoon, so I could partion another ssd. Is the sector alignment value the same on the 128 gig Samsung 840.

frostschutz wrote:

vasettoo wrote:

I have the same SSD and following these steps aligning has been OK for me.

Code:

# blockdev --getalignoff /dev/sda6
0

Don't worry so much about alignment and write cycles. MiB alignment you get pretty much automatically (any tool does that nowadays, mdadm / cryptsetup / lvm etc. all changed their defaults in that regard if it wasn't already MiB aligned before). Add a weekly or monthly fstrim to that and you're good.

frostschutz does GNU parted do the alignment automatically? Do I have to at least start at a boundary of a block? what ever that value is?. vasettoo's paste uses a sector alignment value of 3072 and I'm wondering why. I am asking because I used parted here is the output of
gdisk /dev/sda

I've been trying to find out where the boudaries are ( or the size of the blocks) as I have been reading its one important issue. I was going to repartiton my other drive but now I've seen your post I think I'll wait. Hope to hear from you man. I hang around in #gentoo, I use the same nick there too.