In reply to : Eric Auer <e.auer@*.de> > Hi Bertho, trying to reiterate / re-explain my plan / > idea: Fine !
>> 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". (snipped...) 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). Regards -- Czerno ------------------------------------------------------------------------------ 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 Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user