[haiku-bugs] Re: [Haiku] #8990: intel partiton addon allows creating partitions > 2TB (easy)
- From: "pdziepak" <trac@xxxxxxxxxxxx>
- Date: Mon, 26 Jan 2015 13:28:00 -0000
#8990: intel partiton addon allows creating partitions > 2TB (easy)
------------------------------------------+----------------------------
Reporter: luroh | Owner: bonefish
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Partitioning Systems/Intel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
------------------------------------------+----------------------------
Comment (by pdziepak):
Replying to [comment:18 pulkomandy]:
> Replying to [comment:17 kushalsingh007]:
> > An example that blocksize is not always indeed not 512 can be seen
when you try to format the given space to Be File System ( you choose a
value of BlockSize for the same) , and then once it's done then you try to
Initialize Intel partition Map. You will notice there that
partition->BlockSize() is going to return the value chosen by you (not
512),
>
> Then there is a bug there. The intel partition map would erase the BFS
volume in that case, and it should use the physical block size of the
disk.
Yes, it looks like somewhere in the code "file system block size" and
"block device block size" (aka sector) are confused.
> I don't know if it's correct to allow MBR on disks which expose 4K
sectors (note that most consumer grade disk don't, they use "512e" and
expose 512 byte sectors to the BIOS and OS), and I don't know what sector
size the MBR should be using in that case. If we want to be safe, we
shouldn't allow use of MBR when sectors are not reported as 512 bytes by
the drive, at least until we can find reliable information on how this is
handled by the BIOS, our MBR code (I'm fairly sure we don't allocate 4K
RAM for the sector to read there), and the stage1 loader and makebootable,
as well as the kernel and the ata driver. (see
http://en.wikipedia.org/wiki/Advanced_Format#512e , and the following
section on "4K native drives").
>
> So, I would suggest not allowing use of the MBR on non-512 byte drives
until these possible problems have been investigated and we know for sure
the system can boot off a drive which exposes 4K sectors.
AFAIK you need UEFI to boot from 4k disk, but that's not really important
here. Besides, you could still use it as a secondary disk (assuming that
there is no hardcoded sector size anywhere in the OS). Anyway, what I want
to say is that what we do with disks with 4kB logical sectors is
irrelevant in this discussion. However, when the kernel block device layer
and its drivers expose such disk to the rest of the world (including MBR
code) then it should be handled appropriately.
The real problem with the posted patch was (and still is in v2) that it:
1) breaks the size check by hardcoding 512 byte sector size, 2) adds
offset check with hardcoded 512 byte sector size. The correct way to get
the sector size is to use `BlockSize()` as it is done for the currently
used size check. As long as these issues are not corrected in the patch it
has my "nacked-by".
--
Ticket URL: <https://dev.haiku-os.org/ticket/8990#comment:19>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
