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

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: <53FED9A7.3020608@plexistor.com>
Date:	Thu, 28 Aug 2014 10:26:31 +0300
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Matthew Wilcox <willy@...ux.intel.com>
CC:	Jens Axboe <axboe@...com>, Dmitry Monakhov <dmonakhov@...nvz.org>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 3/5] brd: Add getgeo to block ops

On 08/27/2014 08:53 PM, Matthew Wilcox wrote:
> On Wed, Aug 27, 2014 at 06:28:25PM +0300, Boaz Harrosh wrote:
>> We set all hd_geometry members to 1, because this way fdisk
>> math will not try its crazy geometry math and get stuff totally wrong.
>>
>> I was trying to get some values that will make fdisk Want to align
>> first sector on 4K (like 8, 16, 20, ... sectors) but nothing worked,
>> I searched the net the math is not your regular simple multiplication
>> at all.
>>
>> If you managed to get these please tell me. I would love to solve
>> this.
>>
>> But for now we use 4k physical sectors for fixing fdisk alignment
>> issues, and setting these here to something that will not make
>> fdisk serve us with crazy numbers.
> 
> Are you saying that fdisk ignores the 4k physical sectors (that you set up
> in patch 5/5) in favour of the geometry exposed here?  That doesn't make
> sense to me, since it would misalign 4k-physical ATA drives if it did.
> 

No with patch 5/5 the 4k stuff is good.

What I'm saying is that with (64, 32, x) fdisk offers a very high first
sector and with all 1(s) it will allow a low value like 4k

For example with (64, 32, x) + the 4k patch in 5/5 with a 4M brd disk it
will offer 40 (20K) as first possible sector.

With this patch applied it will offer 8 (4K) as first sector, which is what
I want

> I don't see anywhere else in the kernel reporting (1,1,1).  The most common
> form to fake a geometry uses (64, 32, x), including SCSI.
>

But is it wrong? why?

I guess that until now no one cared about wasted space at the beginning
but with brd I do. Your words this is all "fake" then why at all.
With all 1(s) the CHS convoluted math just disappears and gets out of the
way.

This is clearly the case of copy/paste so long in the history of the code
that no one knows why it was done originally, and it has become religion
that if you dare touch it ghost will come out of closets.

But I looked at the code's math and I found that this is better.

And why not let it be a flag to UM that this is RAM based? If legacy
code likes it just fine, why do we think otherwise?

Thanks
Boaz

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