Re: [Freedos-user] Re : Support for 4k byte > sectors

[Eric A. <e....@jp...>]

Hi Bertho,

>>> a DRIVER could interface with any disk with any sector size and
>>> then just provide an int13 or int25/26 interface with 512 byte
>>> "sector" size for data transfer to DOS.

> I'm not opposed to this method, which I see as a workaround rather
> than a fully satisfying answer however.

On one hand, it is in the way of formatting and is less fast.
But on the plus side, it saves RAM for the DOS kernel... :-)

Also, the driver can parse GPT partition tables so it helps
kernels which only understand classic MBR partition tables.

Of course to have > 2 TB in ONE drive letter, you need the
support for big sectors and/or (?) GPT in the kernel itself.

> You insist on FAT32 compatibility , but what about FAT16

FAT32 is more flexible in some aspects, so it is easier to
tell DOS that a FAT32 partition on a 4k-disk is a slightly
odd FAT32 partition on a (virtually) 512-disk than to do
the same for FAT16 or FAT12. Also, what would you do with
such a tiny partition on such a large harddisk? ;-)

> physical Hitachi disk has 512 K sectors, the SATA<>USB bridge already
> does its own 512/4096 conversion (including internal buffering and,
> I'm not sure but possibly, delaying write back)... your proposed
> driver would in effect dutifully cancel the packing/unpacking done by
> the appliance's firmware !

Yeah talk about strange design decisions... The USB box
makes you believe that a 512 byte disk is 4k based and
my suggested DOS driver makes DOS believe that a 4k one
consists of 512 byte units. But unless you change the
USB firmware, there is no way to transfer only those 512
byte sectors to your 512 byte disk in the USB box that
you actually wanted to update, I guess...

>> This means you cannot make the RAW DISK visible to DOS that way,
>> but you ONLY have to show DOS a modified boot sector to make the
>> rest of an otherwise unchanged PARTITION work from "native 4k
>> sectors" into "show DOS 512 byte fake sec size".

> Kind of crippling a device if you ask me.

You probably lose some speed, but this is a general DOS
problem already: Modern disks are below their peak speed
if you access single sectors (even native 4k sectors).
DOS would have to do more pooling and maybe read-ahead.

> the "real"  answer is for the DOS kernel to be able to
> support native 4k sectors

To have a real decent performance, especially (!) on a
large disk, you must not use FAT. Or if you really do
have to use FAT, at least cache the FAT in RAM as Win9x
did. For DOS, that means XMS or similar, a few MB of it.
Or of course implement a decent filesystem like ext2, as
others like NTFS or ext4 will take even more RAM to run.

> 4k buffers aren't /that/ expensive

You should have a few per drive letter and buffers should
be in your HMA, of which 40k of 64k are already filled by
the kernel code. So you want a few times N sectors in 24k
and you suggest to make each buffer 4k instead of 0.5k...

Regards, Eric