In reply to : Eric Auer <e.auer@*.de>
> Hi Bertho, trying to reiterate / re-explain my plan /
>> 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.
> As explained in a longer mail this week, it actually SHOULD
> work: Only a few values in the boot sector would differ from
> a native 4k sector FAT filesystem compared to a filesystem
> where things work in "groups of 8 sectors" of 512 byte each,
> which is exactly what you would get when you make a 4k disk
I'm not opposed to this method, which I see as a workaround rather than a fully
satisfying answer however.
You insist on FAT32 compatibility , but what about FAT16 & even FAT12 ?(Yes I
like having a primary FAT12 partition, 32 MBytes or so, at the start of hard
disks. But this is I ...) Alignment of the data (and FAT) sectors is more
difficult to achieve for DOS partitions of these types than FAT32.
Another potential drawback of the translating driver approach is write
thrashing on sector writes unless disk driver does some delayed-write of its
own, independent of any higher level cache... further complicating the matter.
Finally I need hardly craw attention on a weird effect in the case of the very
device which caused me to start this whole subject : the 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 !
> 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. I'm not saying it wouldn't be usable,
and certainly better than no access at all - still ISTM the "real" answer is
for the DOS kernel to be able to support native 4k sectors (that limit is also
artificial but it seems the right figure at the moment, possibly forever as far
as DOS extended lifetime goes; and 4k buffers aren't /that/ expensive, even
without a special sparing allocation scheme, provided the number of buffers in
fdconfig be kept within reason).
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!
Freedos-user mailing list