All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <boaz@plexistor.com>
To: Karel Zak <kzak@redhat.com>, Jens Axboe <axboe@fb.com>,
	Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <willy@linux.intel.com>,
	Dmitry Monakhov <dmonakhov@openvz.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 5/5] brd: Add getgeo to block ops for fdisk
Date: Sun, 09 Nov 2014 18:57:27 +0200	[thread overview]
Message-ID: <545F9CF7.6090306@plexistor.com> (raw)
In-Reply-To: <20141107092313.GH6880@x2.net.home>

On 11/07/2014 11:23 AM, Karel Zak wrote:
> On Wed, Nov 05, 2014 at 04:10:50PM +0200, Boaz Harrosh wrote:
>> From: Boaz Harrosh <boaz@plexistor.com>
>>
>> Now when fdisk is run on brd it will ask some cryptic
>> questions about CHS. This is because the getgeo block operation
>> is not implemented.
> 
>  Again, what fdisk (util-linux) version?
> 

Hi Karel, Dave and Jens

With Fedora 20 > "fdisk from util-linux 2.24.2"

>> I have done a quick audit of the fdisk code. The CHS calculation
>> is very convoluted but at the end it comes out with a number.
>> Which is taken into consideration in first-sector to allow. With
>> all 1(s) this numbers is very small and other numbers come into
>> account. Also note that if the device is big like 1G (not sure what
>> is the threshold) fdisk will offer 1M (2048) as possible first-
>> sector, and it does not matter what numbers we give here.
> 
>  oh.. sounds like archeology, CHS calculation does not mater in the
>  current code, it follows I/O limits (including crazy alignment
>  offset).
> 

with a small 4M disk

I see brd_getgeo() getting called on fdisk load and when pressing
g or o. But it no longer has any effect at all if I have it defined
returning CHS(4,64,32) or returning CHS(1,1,1) or not defined at all
I get the same exact below experience:
(Dropping the none-relevant prompts)

======== *WITHOUT* 4k physical_block_size PATCH ===============================================================
Command (m for help): g
Command (m for help): n
First sector (34-8158, default 34): 
Last sector, +sectors or +size{K,M,G,T,P} (34-8158, default 8158): 1717
Command (m for help): n
First sector (1718-8158, default 1718): 
# NOTE first sector is last "prev-end" + 1
Last sector, +sectors or +size{K,M,G,T,P} (1718-8158, default 8158): 
Command (m for help): p
  Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: 5C14F69F-EA44-4FE3-984A-9948D6AB7628

  Device      Start          End   Size Type
  /dev/ram0p1    34         1717   842K Linux filesystem
  /dev/ram0p2  1718         8158   3.1M Linux filesystem

---

Command (m for help): o
Command (m for help): n
First sector (1-8191, default 1): 
Last sector, +sectors or +size{K,M,G,T,P} (1-8191, default 8191): 1717
Command (m for help): n
First sector (1718-8191, default 1718): 
# NOTE same here
Last sector, +sectors or +size{K,M,G,T,P} (1718-8191, default 8191): 
Command (m for help): p
  Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: dos
  Disk identifier: 0xe5c9e1b1

  Device      Boot Start       End Blocks  Id System
  /dev/ram0p1          1      1717    858+ 83 Linux
  /dev/ram0p2       1718      8191   3237  83 Linux

======== 4k physical_block_size PATCH ===============================================================

Command (m for help): g
Command (m for help): n
First sector (34-8158, default 40): 
Last sector, +sectors or +size{K,M,G,T,P} (40-8158, default 8158): 1717
Command (m for help): n
First sector (34-8158, default 1720): 
# NOTE 34-8158 again, only with gpt
Last sector, +sectors or +size{K,M,G,T,P} (1720-8158, default 8158): 
Command (m for help): p
  Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 4096 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: 892E3C8A-3942-4C06-9B5B-6BA6B5A84AB9

  Device      Start          End   Size Type
  /dev/ram0p1    40         1717   839K Linux filesystem
  /dev/ram0p2  1720         8158   3.1M Linux filesystem

---

Command (m for help): o
Command (m for help): n
First sector (8-8191, default 8): 
Last sector, +sectors or +size{K,M,G,T,P} (8-8191, default 8191): 1717
Command (m for help): n
First sector (1718-8191, default 1720): 
# NOTE with dos its good
Last sector, +sectors or +size{K,M,G,T,P} (1720-8191, default 8191): 
Command (m for help): p
  Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 4096 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: dos
  Disk identifier: 0xaa069afe

  Device      Boot Start       End Blocks  Id System
  /dev/ram0p1          8      1717    855  83 Linux
  /dev/ram0p2       1720      8191   3236  83 Linux

=======

So I'm dropping the getgeo() patch all together. It is now fixed with new
util-linux 2.24.2 and is not needed at all. (Before fdisk gave me a prompt
on load without it)

Jens please drop this patch titled:
	[PATCH 5/5] brd: Add getgeo to block ops for fdisk

Dave, Karel, what would you say fdisk should do? do you think it behaves correctly
to only align with the 4k-physical_block_size or must it always align ?

So it looks like we still need the 4k-physical_block_size PATCH for current
fdisk, I don't mind if it is decided to be fixed in user-mode then we can
drop this patch as well.

[ For Karel 2 things:
  - It looks like getgeo has no effect (Is it used at all?), you might want to
    remove the call. (libgparted does not use it)
  - Checkout the small bug above with gpt and first-sector of second partition
]

Many Thanks
Boaz

  reply	other threads:[~2014-11-09 16:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 14:00 [PATCHSET 0/5 v3] brd: partition fixes Boaz Harrosh
2014-11-05 14:01 ` [PATCH 1/5] axonram: Fix bug in direct_access Boaz Harrosh
2014-11-05 14:02 ` [PATCH 2/5] block: Change direct_access calling convention Boaz Harrosh
2014-11-05 14:04 ` [PATCH 3/5] brd: Fix all partitions BUGs Boaz Harrosh
2014-11-05 14:08 ` [PATCH 4/5] brd: Request from fdisk 4k alignment Boaz Harrosh
2014-11-05 14:20   ` Martin K. Petersen
2014-11-05 14:43     ` Boaz Harrosh
2014-11-06 17:25       ` Martin K. Petersen
2014-11-07  9:10         ` Karel Zak
2014-11-09 17:52         ` Boaz Harrosh
2014-11-10 17:00           ` Martin K. Petersen
2014-11-05 14:10 ` [PATCH 5/5] brd: Add getgeo to block ops for fdisk Boaz Harrosh
2014-11-05 15:14   ` [PATCH 5/5 v4] " Boaz Harrosh
2014-11-05 15:18     ` Boaz Harrosh
2014-11-07  9:23   ` [PATCH 5/5] " Karel Zak
2014-11-09 16:57     ` Boaz Harrosh [this message]
2014-11-10  9:58       ` Karel Zak
2014-11-10 11:15         ` Boaz Harrosh
2014-11-10 13:26           ` Karel Zak

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=545F9CF7.6090306@plexistor.com \
    --to=boaz@plexistor.com \
    --cc=axboe@fb.com \
    --cc=david@fromorbit.com \
    --cc=dmonakhov@openvz.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@linux.intel.com \
    /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.