linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Jens Axboe <axboe@fb.com>, Dave Chinner <david@fromorbit.com>,
	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: Mon, 10 Nov 2014 10:58:49 +0100	[thread overview]
Message-ID: <20141110095403.GL6880@x2.net.home> (raw)
In-Reply-To: <545F9CF7.6090306@plexistor.com>

On Sun, Nov 09, 2014 at 06:57:27PM +0200, Boaz Harrosh wrote:
> with a small 4M disk

 This is the problem, for small disks (<= 4MiB) we don't use 1MiB
 grain because it does not make sense. For so small devices the grain
 (and the first partition offset) is the same as physical sector size. 

 Try something bigger in your tests :-)

> 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:

 The alignment and topology code is generic, it gathers all
 information about the device, but it's fine if the device does not
 provide HDIO_GETGEO.  The geometry is currently used for DOS
 compatible mode, or SGI and  SUN only.

> ======== 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

 It seems like a fdisk bug, the gap between 34-40 is smaller than phy sector
 size.. I'll fix it, thanks!

> 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 ?

 If you expect partitions aligned to 4K (~pagesize?) then you have to
 provide proper information to userspace (sector size or min/opt_io),
 so from my point of view the patch makes sense.

 Note that for example zram uses 4K logical and physical sector sizes
 as well as all I/O limits are aligned to 4K at all:

 # modprobe zram
 # zramctl --find --size 4MiB
 /dev/zram0

 # fdisk -l /dev/zram0
 Disk /dev/zram0: 4 MiB, 4194304 bytes, 1024 sectors
 Units: sectors of 1 * 4096 = 4096 bytes
 Sector size (logical/physical): 4096 bytes / 4096 bytes
 I/O size (minimum/optimal): 4096 bytes / 4096 bytes


 Is there a reason for brd to behave differently?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-11-10  9:59 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
2014-11-10  9:58       ` Karel Zak [this message]
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=20141110095403.GL6880@x2.net.home \
    --to=kzak@redhat.com \
    --cc=axboe@fb.com \
    --cc=boaz@plexistor.com \
    --cc=david@fromorbit.com \
    --cc=dmonakhov@openvz.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).