sector size

[muta...@gmail.com]

I checked out INT 13H AH=08H and I was surprised
that the sector size wasn't one of the things returned.

Nor could I see another BIOS call that would return
that.

What's the reason that isn't present in the BIOS?

Thanks. Paul.

[Scott Lurndal]

Probably because only one sector size was supported.

[muta...@gmail.com]

On Monday, April 18, 2022 at 11:46:39 PM UTC+10, Scott Lurndal wrote:

> >I checked out INT 13H AH=08H and I was surprised
> >that the sector size wasn't one of the things returned.
> >
> >Nor could I see another BIOS call that would return
> >that.
> >
> >What's the reason that isn't present in the BIOS?

> Probably because only one sector size was supported.

What is the logic behind choosing a sector size?
Could they have chosen a sector size of 1 byte?
Or 4096 right from the start?

Also, is the switch from 512 to 4096 being done
purely because they are exceeding the 32-bit
sector number? Previously when they were using
CHS addressing, basically 24-bit, they switched to
LBA to get the 32 bits. But why not make an
LBA-enhanced that is 64 bits?

Thanks. Paul.

[JJ]

On Mon, 18 Apr 2022 11:16:19 -0700 (PDT), muta...@gmail.com wrote:
>
> What is the logic behind choosing a sector size?
> Could they have chosen a sector size of 1 byte?
> Or 4096 right from the start?
>
> Also, is the switch from 512 to 4096 being done
> purely because they are exceeding the 32-bit
> sector number? Previously when they were using
> CHS addressing, basically 24-bit, they switched to
> LBA to get the 32 bits. But why not make an
> LBA-enhanced that is 64 bits?
>
> Thanks. Paul.

A sector consist not just user data area, but also identification marker,
address, synchronization marker, and gaps - which also consume space on the
physical media. See Int 1Eh Diskette Parameter table. More details can be
found in IBM PC Technical Reference document.

Having too small sector size increases the space required for those data.
It'd be kind of like overhead of a file system, but in this case, a disk's
sector layout within a track.

The unformatted capacity of a floppy disk is the raw capacity before being
used for those formatting data - which is quite larger than the formatted
one. e.g. 2MB unformatted for 1.44MB format.

Custom high capacity floppy disk formats such as 2M/3M, Microsoft DMF, and
IBM XDF, shrink the gap lengths to make room for additional sectors. IBM XDF
mixes sector sizes in the same track.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Monday, April 18, 2022 at 11:46:39 PM UTC+10, Scott Lurndal wrote:
>
>> >I checked out INT 13H AH=08H and I was surprised
>> >that the sector size wasn't one of the things returned.
>> >
>> >Nor could I see another BIOS call that would return
>> >that.
>> >
>> >What's the reason that isn't present in the BIOS?
>
>> Probably because only one sector size was supported.
>
>What is the logic behind choosing a sector size?
>Could they have chosen a sector size of 1 byte?
>Or 4096 right from the start?

There are a number of factors that go into the
selection of the sector size. In this case,
512 was probably derived from the VAX where
the sector size was chosen to match the
page size to facility paging (or possibly
vice versa).

Likewise 4096 matches the smallest page size on
most modern processors (e.g. x86, arm, MIPS,
PPC, etc).

IBM was more interested in tracks than sectors.

Burroughs used 100-byte and 180-byte sectors.

>
>Also, is the switch from 512 to 4096 being done
>purely because they are exceeding the 32-bit
>sector number?

No, it's for efficiency. As JJ noted, a larger
sector size is more space efficient on spinning
rust media. It's also more time-efficient.

For solid state media, the sector sizes are purely
arbitrary.

[muta...@gmail.com]

On Monday, April 18, 2022 at 11:46:39 PM UTC+10, Scott Lurndal wrote:

Next question - what is the philosophy for updating
the BIOS? E.g. what would be the logical place to add
a BIOS query for sector size?

Thanks. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Monday, April 18, 2022 at 11:46:39 PM UTC+10, Scott Lurndal wrote:
>
>> "muta...@gmail.com" <muta...@gmail.com> writes:
>> >I checked out INT 13H AH=08H and I was surprised
>> >that the sector size wasn't one of the things returned.
>> >
>> >Nor could I see another BIOS call that would return
>> >that.
>> >
>> >What's the reason that isn't present in the BIOS?
>
>> Probably because only one sector size was supported.
>
>Next question - what is the philosophy for updating

It's simple. BIOS has been replaced by the far more
useful and extensible UEFI firmware. There is no
point in updating an obsolete bit of code that was
obsolete the day it was introduced by IBM.

[JJ]

On Wed, 20 Apr 2022 15:07:50 -0700 (PDT), muta...@gmail.com wrote:
>
> Next question - what is the philosophy for updating
> the BIOS? E.g. what would be the logical place to add
> a BIOS query for sector size?
>
> Thanks. Paul.

BIOS already have functions for that. Why add another?

Or, are you trying to query the physical sector size directly from the
harddisk, bypassing BIOS translation? If this is the case, Int 13 still has
some unused service numbers.

[muta...@gmail.com]

On Friday, April 22, 2022 at 5:49:11 AM UTC+10, JJ wrote:

> > Next question - what is the philosophy for updating
> > the BIOS? E.g. what would be the logical place to add
> > a BIOS query for sector size?

> BIOS already have functions for that. Why add another?

Which function gives me sector size?

> Or, are you trying to query the physical sector size directly from the
> harddisk, bypassing BIOS translation? If this is the case, Int 13 still has
> some unused service numbers.

No, I don't want to bypass the BIOS translation. I just want
the BIOS to tell me what sector size I should use.

If the BIOS doesn't already do that, then I'd like to know how
the BIOS should best be extended. You've suggested a new,
unused, function code, which answers my question.

Thanks. Paul.

[JJ]

On Thu, 21 Apr 2022 18:15:22 -0700 (PDT), muta...@gmail.com wrote:
> On Friday, April 22, 2022 at 5:49:11 AM UTC+10, JJ wrote:
>
>>> Next question - what is the philosophy for updating
>>> the BIOS? E.g. what would be the logical place to add
>>> a BIOS query for sector size?
>
>> BIOS already have functions for that. Why add another?
>
> Which function gives me sector size?

Int 13 Extension AH=48h Get Drive Parameter. Offset 18h of the returned
data.

Though, it's only for harddisk. You'll have to create a new function for
floppy drives, by reading the Disk Parameter data from Int 1E vector, after
the media is accessed. But it can't be accurate, since floppy disks may have
variable sector sizes if they're using custom format.

[muta...@gmail.com]

On Friday, April 22, 2022 at 10:56:00 PM UTC+10, JJ wrote:

> > Which function gives me sector size?

> Int 13 Extension AH=48h Get Drive Parameter. Offset 18h of the returned
> data.

Thanks a lot! That's exactly what I needed.

BFN. Paul.

[muta...@gmail.com]

I think I want PDOS/86 to support sectors up to
32k in size, which would switch the maximum
hard disk size from 2 TB to 128 TB.

Current hard disks max out at about 20 TB in size.

Which exceeds the ability of 4096-byte sectors
actually (16 TB).

BFN. Paul.

[muta...@gmail.com]

On Saturday, April 23, 2022 at 7:30:35 AM UTC+10, muta...@gmail.com wrote:

> I think I want PDOS/86 to support sectors up to
> 32k in size, which would switch the maximum
> hard disk size from 2 TB to 128 TB.

Actually, I may as well go for up to 65535 byte
sectors.

BFN. Paul.

[JJ]

On Fri, 22 Apr 2022 16:01:03 -0700 (PDT), muta...@gmail.com wrote:
>
> Actually, I may as well go for up to 65535 byte
> sectors.
>
> BFN. Paul.

I don't think 64K sector size would be in my life time. :)

My quick research tells me that 512 sector size was introduced in 1977. 4K
sector was introduced in 2010. So, it took 33 years, from 512 to 4K -
skipping 1K and 2K. Since technology is growing exponentially, the next leap
might be on 2025 or it may take another 30 years or so - on 2040. With 8K or
16K.

[wolfgang kern]

So you became a hard disk manufacturer yet?

ATA PIO mode supports LBA48 (2^48 sectors)
=281.14749767E12 sectors, *512 = 144E15 byte
=128000 TB (or call that 128 HB if you like).
this 4K sectors joined in for lower costs and
speed reasons, it wasn't a size issue.
__
wolfgang

[muta...@gmail.com]

On Sunday, April 24, 2022 at 12:50:05 AM UTC+10, wolfgang kern wrote:

> this 4K sectors joined in for lower costs and
> speed reasons, it wasn't a size issue.

Thanks for that info.

In that case - do you know what happens with a
disk drive that has 4096-byte sectors and a BIOS?

If you do a BIOS INT 13H to read a sector using LBA,
does it read 512 bytes or 4096 bytes?

Thanks. Paul.

[wolfgang kern]

On 24/04/2022 02:33, muta...@gmail.com wrote:
> On Sunday, April 24, 2022 at 12:50:05 AM UTC+10, wolfgang kern wrote:
>
>> this 4K sectors joined in for lower costs and
>> speed reasons, it wasn't a size issue.
>
> Thanks for that info.
>
> In that case - do you know what happens with a
> disk drive that has 4096-byte sectors and a BIOS?

it depends on the age of the BIOS, 4K HDs can be read
on 512 byte bounds anyway (just a bit slower then)

> If you do a BIOS INT 13H to read a sector using LBA,
> does it read 512 bytes or 4096 bytes?

512 bytes, 4k aligned read/writes are recommended for
speed reasons only.
__
wolfgang

[muta...@gmail.com]

On Sunday, April 24, 2022 at 11:49:58 AM UTC+10, wolfgang kern wrote:

> > In that case - do you know what happens with a
> > disk drive that has 4096-byte sectors and a BIOS?

> it depends on the age of the BIOS, 4K HDs can be read
> on 512 byte bounds anyway (just a bit slower then)

> > If you do a BIOS INT 13H to read a sector using LBA,
> > does it read 512 bytes or 4096 bytes?

> 512 bytes, 4k aligned read/writes are recommended for
> speed reasons only.

Sorry, I don't understand. I'm not concerned about
alignment.

If I have a buffer that is 512 bytes in size, and I do a BIOS
call to read LBA sector 2:

1. Will the first 8192 bytes of the disk be skipped, because
that is occupied by LBA 0 and LBA 1?

2. Will my buffer get overrun, and 3584 bytes of my other
code/data get trashed?

Thanks. Paul.

[wolfgang kern]

On 24/04/2022 06:16, muta...@gmail.com wrote:
> On Sunday, April 24, 2022 at 11:49:58 AM UTC+10, wolfgang kern wrote:
>
>>> In that case - do you know what happens with a
>>> disk drive that has 4096-byte sectors and a BIOS?
>
>> it depends on the age of the BIOS, 4K HDs can be read
>> on 512 byte bounds anyway (just a bit slower then)
>
>>> If you do a BIOS INT 13H to read a sector using LBA,
>>> does it read 512 bytes or 4096 bytes?
>
>> 512 bytes, 4k aligned read/writes are recommended for
>> speed reasons only.

> Sorry, I don't understand. I'm not concerned about
> alignment.

It's recommended to write files starting at 4K bounds,
that is ie: LBA 0,8,16,24 and so on to avoid additional
cache reads and head moves, so fit HD-internal bounds.
Misaligned read/write may cost one full disk revolution,
that's usually 1/7200 Sec, means many thousand CPU cycles.

> If I have a buffer that is 512 bytes in size, and I do a BIOS
> call to read LBA sector 2:
> 1. Will the first 8192 bytes of the disk be skipped, because
> that is occupied by LBA 0 and LBA 1?

No, if it's a 4k HD then its internal cache will be loaded with
LBA 0..7 but the I/O-port is only fed with 512 bytes from LBA2.

> 2. Will my buffer get overrun, and 3584 bytes of my other
> code/data get trashed?

As long there is no weird UEFI/GPT assignment it wont overrun.
But if you like to be on the save side make your buffer 4K :)
__
wolfgang

[muta...@gmail.com]

On Sunday, April 24, 2022 at 9:59:07 PM UTC+10, wolfgang kern wrote:

> It's recommended to write files starting at 4K bounds,
> that is ie: LBA 0,8,16,24 and so on to avoid additional
> cache reads and head moves, so fit HD-internal bounds.
> Misaligned read/write may cost one full disk revolution,
> that's usually 1/7200 Sec, means many thousand CPU cycles.

I see, thanks.

> > If I have a buffer that is 512 bytes in size, and I do a BIOS
> > call to read LBA sector 2:

> > 1. Will the first 8192 bytes of the disk be skipped, because
> > that is occupied by LBA 0 and LBA 1?

> No, if it's a 4k HD then its internal cache will be loaded with
> LBA 0..7 but the I/O-port is only fed with 512 bytes from LBA2.

Wow. In that case, I won't bother supporting sector
sizes other than 512 for now. There are other priorities.

BFN. Paul.

[Joe Monk]

A good read: https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

Joe

[muta...@gmail.com]

On Monday, April 25, 2022 at 6:09:21 AM UTC+10, Joe Monk wrote:

> A good read: https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

Thanks. So really all I need to do is make sure that
when I write or obtain an fdisk utility, I need to make
sure that all partitions are aligned on an 8-sector
boundary.

There's no need for me to change existing PDOS itself,
even though it has 512 sectors only.

BFN. Paul.

[wolfgang kern]

On 24/04/2022 22:09, Joe Monk wrote:
> A good read: https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

Yes, this is a good hint.
__
wolfgang

[Joe Monk]

> Thanks. So really all I need to do is make sure that
> when I write or obtain an fdisk utility, I need to make
> sure that all partitions are aligned on an 8-sector
> boundary.
>

No, you need to make sure that your partitions are aligned on 1MB boundaries (2048 sectors).

Joe

[wolfgang kern]

any reason for this 1MB ?

while my not supporting NTFS OS mainly have 64GB partitions, all my
partitions are 2GB aligned because 2GB became finally my minimum size.
__
wolfgang

[Joe Monk]

> any reason for this 1MB ?
>
> while my not supporting NTFS OS mainly have 64GB partitions, all my
> partitions are 2GB aligned because 2GB became finally my minimum size.

2GB is aligned on a 1MB boundary (2048MB).

Joe

[wolfgang kern]

:) this is obvious of course but the question why you said 1MB remains.
__
wolfgang

[Scott Lurndal]

Probably because if you start the first partition at 2GB, you're wasting
the first 2GB (since the MBR can't be part of the first partition). Granted
that's only 1% of a 2TB drive.

[wolfgang kern]

I don't see your point here, why do you think the MBR can't be part of
the first partition ? My OS reside and start at partition LBA_0 and this
sector already contains all required start-up code.

or are you arguing just for the sake of it?
__
wolfgang

[Scott Lurndal]

wolfgang kern <now...@nevernet.at> writes:
>On 02/05/2022 15:51, Scott Lurndal wrote:
>> wolfgang kern <now...@nevernet.at> writes:
>>> On 01/05/2022 21:55, Joe Monk wrote:
>>>>> any reason for this 1MB ?
>>>>> while my not supporting NTFS OS mainly have 64GB partitions, all my
>>>>> partitions are 2GB aligned because 2GB became finally my minimum size.
>>>> 2GB is aligned on a 1MB boundary (2048MB).
>>> :) this is obvious of course but the question why you said 1MB remains.
>
>> Probably because if you start the first partition at 2GB, you're wasting
>> the first 2GB (since the MBR can't be part of the first partition). Granted
>> that's only 1% of a 2TB drive.
>
>I don't see your point here, why do you think the MBR can't be part of
>the first partition ? My OS reside and start at partition LBA_0 and this
>sector already contains all required start-up code.

Why would you want the MBR as part of a filesystem partition? They're
completely different and distinct entities.

Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00003fea

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 17426432 122284031 52428800 83 Linux
/dev/sda3 122284032 312581807 95148888 5 Extended
/dev/sda5 122286080 312580095 95147008 83 Linux

>
>or are you arguing just for the sake of it?

No, I'm legitimately questioning the wisdom of including
the MBR[*] in any partition assigned to a filesystem. If you
want to create a partition for the MBR alone, that's up to
you, but given the limitations on the number of partitions
and alignment requirements in the legacy MBR it seems unwise.

[*] Actually, I'd question the use of MBR itself, given the
flexibility, safety (e.g. backup labels) and ubiquity of GPT tools.

[wolfgang kern]

On 03/05/2022 20:15, Scott Lurndal wrote:

>>>>>> any reason for this 1MB ?
>>>>>> while my not supporting NTFS OS mainly have 64GB partitions, all my
>>>>>> partitions are 2GB aligned because 2GB became finally my minimum size.
>>>>> 2GB is aligned on a 1MB boundary (2048MB).
>>>> :) this is obvious of course but the question why you said 1MB remains.

>>> Probably because if you start the first partition at 2GB, you're wasting
>>> the first 2GB (since the MBR can't be part of the first partition). Granted
>>> that's only 1% of a 2TB drive.

>> I don't see your point here, why do you think the MBR can't be part of
>> the first partition ? My OS reside and start at partition LBA_0 and this
>> sector already contains all required start-up code.

> Why would you want the MBR as part of a filesystem partition? They're
> completely different and distinct entities.

see below

> Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00003fea

> Device Boot Start End Blocks Id System
> /dev/sda1 * 2048 1026047 512000 83 Linux
> /dev/sda2 17426432 122284031 52428800 83 Linux
> /dev/sda3 122284032 312581807 95148888 5 Extended
> /dev/sda5 122286080 312580095 95147008 83 Linux

My OS doesn't support but recognizes NTFS, EXFAT and Loonix.
it got a very own (never fragmenting and never swapping) FS.
So it even doesn't have VBR apart from MBR, all info is found
already in the first sector.

But my four partition entries at the end of LBA_0 are:

1st type0x4b ("K") 64GB or less for my KESYS (points to self)
windoze don't know "K" and therefore doesn't touch it.
2nd and up may contain any other type and could also have
MBR and VBR the usual way and I can make my OS boot them
without the help of a BIOS.

>> or are you arguing just for the sake of it?

> No, I'm legitimately questioning the wisdom of including
> the MBR[*] in any partition assigned to a filesystem. If you
> want to create a partition for the MBR alone, that's up to
> you, but given the limitations on the number of partitions
> and alignment requirements in the legacy MBR it seems unwise.

> [*] Actually, I'd question the use of MBR itself, given the
> flexibility, safety (e.g. backup labels) and ubiquity of GPT tools.

I'd never use C-created tools.
my OS is safe because it doesn't blindly allow boot from partitions.
It is as flexible or even more as any other OS. UEFI and GPT seem to
spoil my concept, but there are ways to override that.

so I repeat my question: why 1MB ?
__
wolfgang

[Scott Lurndal]

wolfgang kern <now...@nevernet.at> writes:
>On 03/05/2022 20:15, Scott Lurndal wrote:

>
>My OS doesn't support but recognizes NTFS, EXFAT and Loonix.

Plonk.