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
next prev parent 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.