Hi Bret, yes you would see a problematic mismatch if you were to talk raw SCSI or CHS to a disk while being inconsistent about whether you use 512 byte or rather 4096 bytes per sector...
However, when DOS "mounts" a partition with help of a loadable block device driver, nothing would access the raw view of the disk. In any case the kernel will not, it will only talk to the block device driver. Anything beyond that is of course evil, but so is dosfsck-ing a partition in Linux while it is mounted at the same time. Can you recommend any free int 13 or block device based delayed / pooled write caching software? As far as I can remember, all "modern" (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. >> ... This is why I suggest to first grow such a file to the final >> size, putting all FAT writes into ONE access and then writing the >> file's contents in large N kB chunks. > > Excellent idea, especially with USB. Thanks, but can you benchmark it? ;-) >> So you actually do the "virtual trick" the other way around? ... > if a buffer is 2048 and the sectors are only 512, the > last 1536 bytes of the buffer are simply never used. Ah, I had understood that you were showing a group of 4 native 512 byte sectors as if they were a 2k sector. > Yes. But for reasons already discussed, this should not be done by > virtualizing the sector size -- that is asking for problems, IMHO. Only if you can look beyond the virtualization in a bad way... For example the same issue existed with ontrack ezdrive "drivers" installed in the master boot record: When you booted a native-LBA-enabled operating system, the disk contents would appear shifted compared to the virtual LBA as seen while the driver is loaded... Only those versions of such drivers which tried to hide the space taken up by the driver suffered from the problem. In the suggested "virtual 512 byte sector" scenario, no shifting happens, BUT DOS is allowed to write in units of 512 bytes. Therefore, the "virtual 512 byte sector" block device driver must NOT allow DOS to re-format the partition because that would allow DOS to place things which have to be whole native 4k sectors at fractional locations. Also, DOS must NOT be allowed to repartition the disk, but that is easily done by not giving int 13 access to it. Block device drivers do not provide int13 anyway, so that one is easy? As long as DOS is not able to change partitioning or boot sector, the whole set of FAT32 structures will stay nicely aligned to 4k units. Apart from that, I still believe: Convert the BPB and boot sector on the fly, and DOS will be totally fine with looking at (and writing to!) a native 4k sector partition through "looks like 512" glasses... :-) And of course it is nice that the magic values are just before the end of the first 512 bytes even when the native sector size is larger, makes things easy. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
