Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[Toni Mas]

I could be an offset defined.
Could you post following files?

/sys/block/sdd/queue/optimal_io_size
/sys/block/sdd/queue/minimum_io_size
/sys/block/sdd/alignment_offset
/sys/block/sdd/queue/physical_block_size
/sys/block/sdd/queue/logical_block_size






Toni Mas

Missatge de Sergey Spiridonov  del dia dc., 4 de des.
2019 a les 13:30:
>
> Hi all
>
> I am trying to partition 14TB HDD and get the following problem with an
> alignment:
>
> # hdparam -I /dev/sdd tells that
>
> Logical  Sector size:   512 bytes
> Physical Sector size:  4096 bytes
>
>
> # parted -a opt /dev/sdd
>
> (parted) mkpart primary 0% 100%
> ...
>
> (parted) print
>
> Number  Start   End SizeFile system  Name Flags
>  1  33,6MB  14,0TB  14,0TB   primary
>
> Now checking alignment:
>
> (parted) align-check opt
> 1 1 aligned
>
>
> So far, so good. Now let's look at the same disk with fdisk:
>
> # fdisk /dev/sdd
>
> : p
>
> Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
> Disk model: IB-366StU3+B
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> Disklabel type: gpt
> Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26
>
> Device Start End Sectors  Size Type
> /dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem
>
> Partition 1 does not start on physical sector boundary.
>
>
> What? Why?
>
>
> man parted tells that
>
>optimal
>   Use optimum alignment as given by the disk
>   topology  in‐ formation.  This  aligns  to  a
>   multiple of the physical block size in a way that
>   guarantees optimal performance
>
>
> 1. Probably parted detected physical sector size as 512
> instead of 4096? Why?
>
> 2. Even if parted thinks that physical sector is 512 instead of
> 4096, why start from 65535 and not from 65536? What is the logic
> behind? How using odd multiplier can improve performance?
>
> Is it a bug in parted or I am missing something?
> --
> Best regards, Sergey Spiridonov
>
>
>

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[David Wright]

On Wed 04 Dec 2019 at 13:15:51 (+0100), Sergey Spiridonov wrote:
> I am trying to partition 14TB HDD and get the following problem with an 
> alignment:
> 
> # hdparam -I /dev/sdd tells that 
> 
>   Logical  Sector size:   512 bytes
>   Physical Sector size:  4096 bytes
> 
> # parted -a opt /dev/sdd
> 
> (parted) mkpart primary 0% 100%
> ...
> (parted) print 
> 
> Number  Start   End SizeFile system  Name Flags
>  1  33,6MB  14,0TB  14,0TB   primary
> 
> Now checking alignment:
> 
> (parted) align-check opt
> 1 1 aligned
> 
> So far, so good. Now let's look at the same disk with fdisk:
> 
> # fdisk /dev/sdd
> : p
> 
> Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
> Disk model: IB-366StU3+B
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> Disklabel type: gpt
> Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26
> 
> Device Start End Sectors  Size Type
> /dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem
> 
> Partition 1 does not start on physical sector boundary.
> 
> What? Why?
> man parted tells that
> 
>optimal
>   Use optimum alignment as given by the disk
>   topology  in‐ formation.  This  aligns  to  a
>   multiple of the physical block size in a way that
>   guarantees optimal performance
> 
> 1. Probably parted detected physical sector size as 512
> instead of 4096? Why?
> 
> 2. Even if parted thinks that physical sector is 512 instead of
> 4096, why start from 65535 and not from 65536? What is the logic
> behind? How using odd multiplier can improve performance?
> 
> Is it a bug in parted or I am missing something?

Bug #923561 has a long discussion about alignment and optimal transfer
size, and it would appear to be a bit of a mess, with no conclusion on
the root cause of the problem, how to document it, or which software
should deal with it (as best I can understand it).

I think the straightforward way of coping with this is to use the
"unit s" command (so that sectors are the default unit), and then
create the partition with something like:
(parted) mkpart primary 2048s 100%
ie give an explicit alignment.

(I've always used gdisk for creating partitions ever since GPT disks
came on the scene, worked in sectors, and relied on gdisk to calculate
the last sector number.)

Regardless of the partitioning, I see messages like:
Optimal transfer size 33553920 bytes not a multiple of physical block size 
(2048 bytes)
Optimal transfer size 33553920 bytes not a multiple of physical block size 
(4096 bytes)
Optimal transfer size 268431360 bytes not a multiple of physical block size 
(16384 bytes)
in the kernel log when I plug some of my disks in. Adding to the
mystery, the first two messages quoted here were given by the same
1TB disk. fdisk agrees with 4096 as the physical block size.
This leads me to ignore the transfer size, let alone calculate
anything from it.

Cheers,
David.

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[Pascal Hambourg]

Le 04/12/2019 à 13:15, Sergey Spiridonov a écrit :


Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26

Device Start End Sectors  Size Type
/dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem

Partition 1 does not start on physical sector boundary.

What? Why?


Probably because of the reported "optimal" I/O size.
65535 * 512 = 33553920

Don't know where this value is taken from.

Re: Partition alignment

[Pascal Hambourg]

Le 04/02/2017 à 14:49, Thomas Hungenberg a écrit :


I have a 4TB HDD with 4k sectors:

Disk /dev/sdb: 976754642 sectors, 3.6 TiB
Logical sector size: 4096 bytes

I would like to set up a single partition using GPT.

gdisk sets up the partition to start at sector 8 by default:

Number  Start (sector)End (sector)  Size   Code  Name
   1   8   976754636   3.6 TiB 8300  Linux filesystem


I have no experience with 4Kn disks yet but this surprises me because 
the default alignment is 2048 sectors or 1 MiB (the two numbers match 
only with 512-bytes sectors, so I don't know which one applies with 4KiB 
sectors).


According to gdisk's manpage, 8 sectors is the minimum alignment that 
gdisk will automatically select if it detects a lower alignment value 
from existing partitions on a disk larger than 300 GB.


How did you proceed exactly ? Did you create a new partition table with 
gdisk (not only a new partition on an existing partition table) ? If you 
kept the existing partition table, was it empty or did it contain some 
partitions that you deleted prior to creating the new partition ?



According to this howto


the first partition should start at sector 65535 with my HDD's parameters:

# cat /sys/block/sdb/queue/optimal_io_size
268431360


Is it a real single hard disk drive or some logical aggregated volume 
created with hardware RAID, SAN, iSCSI or so ?


If it is a real single disk, then the "optimal" I/O size (265 MiB !) 
looks ridiculously big to me.



So I wonder which start sector I should choose for optimal alignment?


A 4Kn disk does not need any alignment. Only 512e Advanced Format disks 
(with 4-KiB physical sectors and 512-byte logical sectors) need to be 
aligned on physical sectors, and SSD need to be aligned on write/erase 
blocks (1 MiB should be fine). Anyway you can choose the standard 1-MiB 
alignment. But if it is a logical aggregated volume, this is a different 
issue. For example with RAID 5 you should align with RAID stripes.

Partition alignment

[Thomas Hungenberg]

Hi,

I have a 4TB HDD with 4k sectors:

Disk /dev/sdb: 976754642 sectors, 3.6 TiB
Logical sector size: 4096 bytes

I would like to set up a single partition using GPT.

gdisk sets up the partition to start at sector 8 by default:

Number  Start (sector)End (sector)  Size   Code  Name
   1   8   976754636   3.6 TiB 8300  Linux filesystem

gdisk then is fine with the alignment:

No problems found. 2 free sectors (8.0 KiB) available in 1
segments, the largest of which is 2 (8.0 KiB) in size.

However, parted says the partition is not aligned:

# parted /dev/sdb align-check opt 1
1 not aligned


According to this howto


the first partition should start at sector 65535 with my HDD's parameters:

# cat /sys/block/sdb/queue/optimal_io_size
268431360
# cat /sys/block/sdb/queue/physical_block_size
4096

268431360 / 4096 = 65535

So I changed the start sector accordingly:

Number  Start (sector)End (sector)  Size   Code  Name
   1   65535   976733639   3.6 TiB 8300  Linux filesystem

Now parted is fine with the alignment:

# parted /dev/sdb align-check opt 1
1 aligned

But gdisk complains:

Caution: Partition 1 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.


So I wonder which start sector I should choose for optimal alignment?


Thanks,
Thomas

Re: SSD partition alignment considerations

[Stan Hoeppner]

On 5/30/2011 10:39 PM, Cam Hutchison wrote:
 I'm about to do a fresh install of Debian onto a new box with a Crucial
 M4 128GB SSD. I want to ensure that I get the best performance I can out
 of the SSD so I want to make sure I take care of any partition alignment
 issues.
 
 I have read tytso's blog post
 (http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size)
 but that post is a couple of years old now and may not be relevant.
 Also, I cannot find any specific information on the M4's erase block
 size but some hints suggest it may be 512kiB, not the 128kiB used in
 that blog post (and the c/h/s settings no longer work for 512kiB
 alignment).
 
 It is necessary to worry about alignment anymore with modern SSDs? The
 Debian installer did not seem to have any special handling that I could
 see, so I suspect I would have to pre-partition the drive and tell the
 installer to use the existing partitions.

General consensus is to start your first partition at 1,048,576 bytes,
as it is evenly divisible by 512, 4096, 131,072, and 524,288 bytes,
covering all sector, filesystem block, and erase block size possibilities.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de4a4c6.2030...@hardwarefreak.com

Re: SSD partition alignment considerations

[Tony van der Hoff]

On 31/05/11 10:20, Stan Hoeppner wrote:


General consensus is to start your first partition at 1,048,576 bytes,
as it is evenly divisible by 512, 4096, 131,072, and 524,288 bytes,
covering all sector, filesystem block, and erase block size possibilities.


General consensus by whom, Stan? Have you any references?

--
Tony van der Hoff  | mailto:t...@vanderhoff.org
Ariège, France |


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4de4a73b.3020...@vanderhoff.org

Re: SSD partition alignment considerations

[Jörg-Volker Peetz]

OCZ has an informative and still active user forum regarding SSD:
http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment
-- 
Best regards,
Jörg-Volker.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/is2iui$6k9$1...@dough.gmane.org

SSD partition alignment considerations

[Cam Hutchison]

I'm about to do a fresh install of Debian onto a new box with a Crucial
M4 128GB SSD. I want to ensure that I get the best performance I can out
of the SSD so I want to make sure I take care of any partition alignment
issues.

I have read tytso's blog post
(http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size)
but that post is a couple of years old now and may not be relevant.
Also, I cannot find any specific information on the M4's erase block
size but some hints suggest it may be 512kiB, not the 128kiB used in
that blog post (and the c/h/s settings no longer work for 512kiB
alignment).

It is necessary to worry about alignment anymore with modern SSDs? The
Debian installer did not seem to have any special handling that I could
see, so I suspect I would have to pre-partition the drive and tell the
installer to use the existing partitions.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f97.4de462f3.b4...@getafix.xdna.net

Squeeze installer and partition alignment

[Todd A. Jacobs]

Does anyone know if the guided partitioning in Squeeze aligns
partitions, and if so to what boundaries? A quick scan of the archives
doesn't turn up anything conclusive.

I'm not sure if realigning partition boundaries for an encrypted lvm
would be any harder (or potentially dangerous for the data) than
aligning a regular partition, but it would be nice if the problem
just...wasn't. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=OX7xKpx4DxWEp5232n4qBEwJb1uyws8XG=1...@mail.gmail.com

Re: Squeeze installer and partition alignment

[Tom H]

On Wed, Mar 23, 2011 at 6:17 AM, Todd A. Jacobs
codegnome.consulting+deb...@gmail.com wrote:

 Does anyone know if the guided partitioning in Squeeze aligns
 partitions, and if so to what boundaries? A quick scan of the archives
 doesn't turn up anything conclusive.

Unless I'm imagining things, there was a recent thread about this and
more than one poster suggested that it's best to format a disk outside
the installer's control to be sure.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTik6uGoH+fRYSx54q49Qey7cbzNGsMJZq=g69...@mail.gmail.com