On Mon, 5 Mar 2012 23:33:20 +0700
Pandu Poluan <pandu@poluan.info> wrote:
> On Mar 5, 2012 11:04 PM, "Alex Schuster" <wonko@wonkology.org> wrote:
> >
> > Grant writes:
> >
> > > > The performance is only impacted if the sector size is
> > > > something other than 512 bytes. The newer 4K sector size used
> > > > by some higher density drives requires that you start
> > > > partitions on a sector boundary or they will perform badly.
> > > > There isn't an actually performance need to actually start on
> > > > 2048 but the fdisk-type developer folks are doing that to be
> > > > more compatible with newer Windows installations.
> > >
> > > All my drives says this from fdisk:
> > >
> > > Units = sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 512 bytes
> > > I/O size (minimum/optimal): 512 bytes / 512 bytes
> >
> > Neither fdisk nor hdparm seem to get the correct sector size, at
> > least not always. That's what I read somewhere (and not only once),
> > and it's true for my own 2TB drive which I know to have a 4K sector
> > size. I'd say you have to look up the specs on the vendor's web
> > size to be sure.
> >
> > > So it doesn't matter where the first partition starts?
> >
> > If you have 4K sectors (and not a Seagate drive with SmartAlign
> >[*]), it does.
> >
> > BTW, here's some benchmarks I just stumbled upon:
> >
> http://hothardware.com/Articles/WDs-1TB-Caviar-Green-w-Advanced-Format-Windows-XP-Users-Pay-Attention/?page=2
> >
> >[*] I don't want to sound like I'm advertising for Seagate here,
> > but at least it seems that with SmartAlign the performance impact
> > will be much less, so it might not be worth the trouble of
> > re-partitioning drives that are already being used.
> >
> > Wonko
> >
>
> The problem with SmartAlign is that..*.* it's magic... once you run
> out of mana, you can kiss your data goodbye.
>
> In other words, I tried to find how it works, but Seagate seems to be
> mum; and that is ungood. Without knowing how exactly the technology
> works, how can we be sure that it won't blow up when encountering
> edge/corner cases?
>
> So, albeit nice (in the sense that one does not have to experience the
> headache in ensuring that partitions are properly aligned), I
> personally will stay away from magical things.
Heretic!!
Beleive the magic you muggle!!
:-)
--
Alan McKinnnon
alan.mckinnon@gmail.com
03-05-2012, 08:33 PM
Joshua Murphy
Gentoo on a Dell XPS 13 Ultrabook
On Mon, Mar 5, 2012 at 11:00 AM, Alex Schuster <wonko@wonkology.org> wrote:
> Grant writes:
>
>> > The performance is only impacted if the sector size is something other
>> > *than 512 bytes. The newer 4K sector size used by some higher density
>> > drives requires that you start partitions on a sector boundary or they
>> > will perform badly. There isn't an actually performance need to
>> > actually start on 2048 but the fdisk-type developer folks are doing
>> > that to be more compatible with newer Windows installations.
>>
>> All my drives says this from fdisk:
>>
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>
> Neither fdisk nor hdparm seem to get the correct sector size, at least
> not always. That's what I read somewhere (and not only once), and it's
> true for my own 2TB drive which I know to have a 4K sector size. I'd say
> you have to look up the specs on the vendor's web size to be sure.
>
>> So it doesn't matter where the first partition starts?
>
> If you have 4K sectors (and not a Seagate drive with SmartAlign[*]), it
> does.
>
> BTW, here's some benchmarks I just stumbled upon:
> http://hothardware.com/Articles/WDs-1TB-Caviar-Green-w-Advanced-Format-Windows-XP-Users-Pay-Attention/?page=2
>
>[*] I don't want to sound like I'm advertising for Seagate here, but at
> least it seems that with SmartAlign the performance impact will be
> much less, so it might not be worth the trouble of re-partitioning drives
> that are already being used.
>
> * * * *Wonko
Also, it counts with SSDs, where alignment,or lack therof, with the
erase block becomes noticeable on write performance. Finding the
actual size of an erase block for most SSDs is rather difficult, but
1MB tends to be a reliable guess as a multiple of *that* as well.
--
Poison [BLX]
Joshua M. Murphy
03-05-2012, 08:41 PM
Mark Knecht
Gentoo on a Dell XPS 13 Ultrabook
On Sun, Mar 4, 2012 at 6:06 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Mar 5, 2012 4:59 AM, "Grant" <emailgrant@gmail.com> wrote:
>>
>>
>> All my drives says this from fdisk:
>>
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>
>> So it doesn't matter where the first partition starts?
>>
>
> Older BIOSes don't understand that hard disks now can have 4KiB sectors, so
> some of the "advanced format" hard disks report a sector size of 512B. But
> behind the scenes, the hard disk maps the logical sector to a subsector of
> the physical sector.
>
> The only sure fire way to find out if your hard disk uses 4KiB sectors is to
> open your computer and eyeball the hard disk. All 4KiB hard disks that I
> know of have statements on their surface that tell me so.
>
> Rgds,
I think I must be kind of late to this conversation, but as background
consider hdparm -i coupled with Google for the actual spec:
With the model number it takes only a minute to determine that this WD
drive is a 4K sector drive. (Which is marked on the drive, as you
state, but I'd have to remove it to find that out.)
Now, in terms of performance, the only requirement (as I understand
it) is that all drive partition be aligned to sector addresses
divisible by 8. (512 * 8 = 4K) The reason 63 gives low performance is
because it's not naturally aligned by 8. With older versions of fdisk
if I started the first partition at 64 then the performance was fine
and only one sector was wasted.
M$, for whatever reason, decided to start at 2048, which is divisible
by 8, reserving the area at the front of the drive for (I think) their
boot loader and other M$-y things. My understanding of why fdisk now
enforces this is simply to be more careful about not overwriting the
M$ boot loaderif it's there. (But I could be very wrong about that!)
Remember, it's possible to make a dual boot system using M$'s loader
instead of grub, and important that fdisk doesn't mangle it when
someone is using that tool.