All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andreas Dilger <adilger@Sun.COM>
Cc: Karel Zak <kzak@redhat.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	util-linux-ng@vger.kernel.org
Subject: Re: [ANNOUNCE] util-linux-ng v2.17 (stable)
Date: Fri, 08 Jan 2010 15:33:17 -0800	[thread overview]
Message-ID: <4B47C0BD.5010700@zytor.com> (raw)
In-Reply-To: <329167C1-CF54-4742-B0B7-AD0B9DEFDEC1@sun.com>

On 01/08/2010 02:40 PM, Andreas Dilger wrote:
> On 2010-01-08, at 14:43, H. Peter Anvin wrote:
>> On 01/08/2010 01:33 AM, Karel Zak wrote:
>>> fdisk:
>>>   - the fdisk command aligns newly created partitions to  
>>> minimum_io_size
>>>     boundary ("minimum_io_size" is physical sector size or stripe  
>>> chunk
>>>     size on RAIDs).
>>>
>>>   - the fdisk command supports disks with alignment_offset now.
>>
>> I think we should align, by default, much more aggressively than  
>> that --
>> because frequently we just don't know what the real physical alignment
>> is (think of flash media, which uses large erase blocks underneath.)
>> Windows aligns partitions 1 MB boundaries by default now -- I think
>> that's probably a reasonably good idea, at least for any disk that's  
>> not
>> tiny, say 256 MB or less.
> 
> I agree whole heartedly.  We steer users very sharply away from using  
> partitions at all, because on h/w RAID devices the 512-byte offset  
> from fdisk completely kills RAID-5/6 performance.
> 
> Making the default minimum alignment for DOS/GPT partitions makes a  
> lot of sense, and LVM PEs should be on 1MB boundaries as well (I don't  
> think that is the case today either).
> 

As far as I can tell, there is absolutely no reason to not align all
partitions, all the time (for both GPT and MBR... GPT may need a "dummy
alignment partition" to fulfill the "no nonpartitioned space" dictum,
although it seems like an impossible requirement in practice -- I think
they main reason for it is to avoid abusers like Grub relying on putting
data in unpartitioned space.)

	-hpa

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
To: Andreas Dilger <adilger-UdXhSnd/wVw@public.gmane.org>
Cc: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	util-linux-ng-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [ANNOUNCE] util-linux-ng v2.17 (stable)
Date: Fri, 08 Jan 2010 15:33:17 -0800	[thread overview]
Message-ID: <4B47C0BD.5010700@zytor.com> (raw)
In-Reply-To: <329167C1-CF54-4742-B0B7-AD0B9DEFDEC1-xsfywfwIY+M@public.gmane.org>

On 01/08/2010 02:40 PM, Andreas Dilger wrote:
> On 2010-01-08, at 14:43, H. Peter Anvin wrote:
>> On 01/08/2010 01:33 AM, Karel Zak wrote:
>>> fdisk:
>>>   - the fdisk command aligns newly created partitions to  
>>> minimum_io_size
>>>     boundary ("minimum_io_size" is physical sector size or stripe  
>>> chunk
>>>     size on RAIDs).
>>>
>>>   - the fdisk command supports disks with alignment_offset now.
>>
>> I think we should align, by default, much more aggressively than  
>> that --
>> because frequently we just don't know what the real physical alignment
>> is (think of flash media, which uses large erase blocks underneath.)
>> Windows aligns partitions 1 MB boundaries by default now -- I think
>> that's probably a reasonably good idea, at least for any disk that's  
>> not
>> tiny, say 256 MB or less.
> 
> I agree whole heartedly.  We steer users very sharply away from using  
> partitions at all, because on h/w RAID devices the 512-byte offset  
> from fdisk completely kills RAID-5/6 performance.
> 
> Making the default minimum alignment for DOS/GPT partitions makes a  
> lot of sense, and LVM PEs should be on 1MB boundaries as well (I don't  
> think that is the case today either).
> 

As far as I can tell, there is absolutely no reason to not align all
partitions, all the time (for both GPT and MBR... GPT may need a "dummy
alignment partition" to fulfill the "no nonpartitioned space" dictum,
although it seems like an impossible requirement in practice -- I think
they main reason for it is to avoid abusers like Grub relying on putting
data in unpartitioned space.)

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-01-08 23:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-08  9:33 [ANNOUNCE] util-linux-ng v2.17 (stable) Karel Zak
2010-01-08  9:33 ` Karel Zak
2010-01-08 21:43 ` H. Peter Anvin
2010-01-08 22:40   ` Andreas Dilger
2010-01-08 22:40     ` Andreas Dilger
2010-01-08 23:33     ` H. Peter Anvin [this message]
2010-01-08 23:33       ` H. Peter Anvin
2010-01-11  6:36     ` Martin K. Petersen
2010-01-11  6:36       ` Martin K. Petersen
2010-01-11  7:27       ` H. Peter Anvin
2010-01-11  7:27         ` H. Peter Anvin
2010-01-11 14:05   ` Pavel Machek
2010-01-11 14:05     ` Pavel Machek
2010-01-11 16:52     ` H. Peter Anvin
2010-01-11 20:17       ` Pavel Machek
2010-01-11 20:17         ` Pavel Machek
2010-01-11 23:26         ` H. Peter Anvin
2010-01-11 23:26           ` H. Peter Anvin
2010-01-12 13:33           ` Artem Bityutskiy
2010-01-12 13:33             ` Artem Bityutskiy
2010-01-12 13:35             ` Artem Bityutskiy
2010-01-12 13:35               ` Artem Bityutskiy
2010-01-11 19:17     ` Artem Bityutskiy
2010-01-11 19:17       ` Artem Bityutskiy
2010-01-12  7:19     ` Jörn Engel
2010-01-12  8:19       ` H. Peter Anvin
2010-01-12  8:19         ` H. Peter Anvin
2010-01-12  9:37         ` Jörn Engel
2010-01-12  9:37           ` Jörn Engel
2010-01-12 16:20           ` H. Peter Anvin
2010-01-12 16:20             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B47C0BD.5010700@zytor.com \
    --to=hpa@zytor.com \
    --cc=adilger@Sun.COM \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=util-linux-ng@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.