[OmniOS-discuss] [zfs] SSD alignment, EFI label rpool support

[Matthew Ahrens]

It's hard for me to see how aligning the partition on a greater granularity
than the physical sector size (aka "ashift", typically 4k for modern large
devices) would help anything.  Regardless of partition alignment, ZFS is
going to write to whatever sectors it wants.

--matt


On Wed, Jul 31, 2013 at 8:22 PM, Paul B. Henson <henson at acm.org> wrote:

> While putting together a linux system, I found the current advice in that
> ecosystem seems to be to align your SSD partitions not just to the page
> size, but to the erase block size. Any thoughts on that recommendation for
> an rpool, l2arc, or zil partition?
>
> I'm using a couple Crucial 256G m4 SSD's for my rpool, which I believe
> have an 8k page size and 512k erase block size. Given the rpool requirement
> for an SMI label, I would end up having to start the slice on cylinder 15
> (which, when added to the one cylinder used by the fdisk label, results in
> cylinder 16) in order to get the alignment right, which wastes something
> like 150Mb :(. Not ridiculous on a 256G device, but annoying. Has any
> progress been made on booting from EFI labeled disks? I vaguely recall
> somebody was working on grub2 but I'm not sure where it ended up. That
> would allow alignment without as much waste.
>
> Or if erase block alignment doesn't matter that much for ZFS I could just
> align to the page size…
>
> Thanks…
>
>
> ------------------------------**-------------
> illumos-zfs
> Archives: https://www.listbox.com/**member/archive/182191/=now<https://www.listbox.com/member/archive/182191/=now>
> RSS Feed: https://www.listbox.com/**member/archive/rss/182191/**
> 21635000-ebd1d460<https://www.listbox.com/member/archive/rss/182191/21635000-ebd1d460>
> Modify Your Subscription: https://www.listbox.com/**
> member/?member_id=21635000&id_**secret=21635000-73dc201a<https://www.listbox.com/member/?member_id=21635000&id_secret=21635000-73dc201a>
> Powered by Listbox: http://www.listbox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20130801/5f61cb18/attachment.html>