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 ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
