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

2019-12-06 Thread 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 de

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

2019-12-05 Thread 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:

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

2019-12-04 Thread 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/sd

Re: Partition alignment

2017-02-05 Thread 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 (sect

Partition alignment

2017-02-04 Thread 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

Re: SSD partition alignment considerations

2011-05-31 Thread 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

Re: SSD partition alignment considerations

2011-05-31 Thread 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 yo

Re: SSD partition alignment considerations

2011-05-31 Thread 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.

SSD partition alignment considerations

2011-05-30 Thread 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.linuxfoundatio

Re: Squeeze installer and partition alignment

2011-03-23 Thread Tom H
On Wed, Mar 23, 2011 at 6:17 AM, Todd A. Jacobs 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 thi

Squeeze installer and partition alignment

2011-03-23 Thread 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)