info-mtools
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Info-mtools] Incorrect assignment of partition type in mformat/mpar


From: Pali Rohár
Subject: Re: [Info-mtools] Incorrect assignment of partition type in mformat/mpartition
Date: Tue, 25 Sep 2018 23:51:29 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Monday 24 September 2018 12:15:18 Pali Rohár wrote:
> On Monday 24 September 2018 07:32:45 Alain Knaff wrote:
> > On 24/09/18 00:05, Pali Rohár wrote:
> > > On Sunday 23 September 2018 23:07:53 Alain Knaff wrote:
> > [...]
> > >> There is only one difference which struck my eye: in order to chose
> > >> between 0x06 and 0x0e you check whether the partition is entirely below
> > >> the 1024 cylinder mark. However, wikipedia claims that the cutoff should
> > >> be at 8GB (or rather 16 G sectors). The Microsoft source cited by
> > >> wikipedia
> > >> (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc977219(v=technet.10)
> > >> claims a cut-off of 4GB...
> > > 
> > > IIRC Microsoft implementations support FAT16 filesystem only up to the
> > > 4GB size. Therefore I guess this is why they specified 4GB limit also
> > > for 0x06 MBR id which belongs to FAT16.
> > > 
> > >> So, now I'm puzzled which of the 3 is correct. Or maybe you still have
> > >> other supporting documentations which you'd like to share? In any case,
> > >> 8GB does indeed roughly correspond to 1024 cylinders if 63 sectors and
> > >> 255 heads are used (which would indeed be picked by LBA assyst for 8GB)
> > > 
> > > I do not have any "official" documentation. But 1024 cylinders is for
> > > sure upper limit. When you are using CHS geometry, then you store 10 bits
> > > for cylinders into MBR partition table. Therefore every CHS partition
> > > must end at 1024th cylinder. And because 0x06 MBR type indicates usage
> > > of CHS, maximal theoretical size is of 0x06 partition in number of
> > > sectors is: sectors * heads * 1024.
> > > 
> > > I guess that people started referring to 8 GB, just because it is "near"
> > > 63*255*1024 sectors (=~ 8032.5 MB =~ 7.84 GB).
> > > 
> > > Number 8 GB itself does not make much sense -- when all addressing was
> > > done by CHS and by DOS interrupts which took tuple (C, H, S).
> > 
> > I see. So I'd go for a combined condition: track must be less than 1024,
> > _and_ size must be less than 4GB
> 
> Mhm... No I remember that I read some MS documentation (do not have link
> right now) that limit 4GB is for 512 sectors disks. And Windows NT for
> disks with larger sector sizes supports FAT16 volumes also larger then
> 4GB. I guess this is just because all addressing in CHS and also in LBA
> stored in MBR partition table is in "sectors" unit.
> 
> Therefore limit specified in bytes, independently of the sector size is
> not correct too.

Here it is:
https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat

FAT16 has support for disks > 4GB on Windows NT 4.0.

Other Windowses, including Windows 2000, do not support it according to
that table. And your link where you found limit to 4GB is for Windows
2000 system.

So I would suggest to just stick with CHS track condition. And allow
sizes also above 4GB.

-- 
Pali Rohár
address@hidden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]