linux-kernel - Re: [PATCH 5/5] brd: Add getgeo to block ops for fdisk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141110095403.GL6880@x2.net.home>
Date:	Mon, 10 Nov 2014 10:58:49 +0100
From:	Karel Zak <kzak@...hat.com>
To:	Boaz Harrosh <boaz@...xistor.com>
Cc:	Jens Axboe <axboe@...com>, Dave Chinner <david@...morbit.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 5/5] brd: Add getgeo to block ops for fdisk

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@...hat.com>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/