> 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...
That's precisely the problem. Depending on which DOS programs you use, some simply call DOS, some may use INT 25h/26h, some may use INT 13h, others may use raw SCSI/ASPI, and there are also other possibilities. If you could force all calls through the DOS device driver, you could eliminate any potential problems with DOS. But DOS doesn't force programs to do that, and there are certain kinds of programs (FDISK, FORMAT, SYS, CHKDSK, SCANDISK, ...) that require low-level access and can't go through the DOS Device Driver. And that doesn't even address the potential issues of using that same device on another OS or BIOS. The potential compatibility problems are just too great for me to even want to attempt this. FYI, my driver provides an INT 13h interface (and I think it's the only one that does). That allows you to use standard DOS utilities to partition and format and create bootable disks, without needing to resort (at least in some cases) to the special Windows and Linux utilities. > 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. It actually isn't "evil" in DOS to do low-level maintenance on a mounted partition. You just need to make sure you flush any buffers and caches, and re-mount if anything that DOS may care about (sector size, number of sectors, cluster size, ...) is changed. In the case of removable media (like USB and floppies), that shouldn't even require a reboot. > 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. I don't know of any, but there's definitely a need for one. I normally don't use caches at all, but when I need one it needs to be a write-delay cache and I use MS SMARTDRV. I actually don't like SMARTDRV very much (it uses too much memory and requires a reboot to uninstall), but I have it and it works OK. I don't find write-through caches like LBACACHE and UIDE to provide enough speed benefit to be very helpful (though they might increase disk life to some degree). In addition, LBACACHE and UIDE are INT 13h caches instead of INT 21h caches (like SMARTDRV is), so they don't work with all disks (including USB and SCSI). When I really need to increase disk access speed (a big problem in some VM's), I copy my commonly-used utilities and batch files to a RAM disk. > Thanks, but can you benchmark it? ;-) I've already done a "simple" benchmark, though I don't think it's exactly what you're looking for. It's discussed on pages 158 and 159 of USBINTRO.DOC (in the "Sector Transfer Size" discussion of the USBDRIVE section). Basically, the speed increases when you "pool" large numbers of contiguous sectors and send them at the same time. A true, valid benchmark would require all sorts of external parameter variability elimination, which I probably won't ever do. > 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: > ... There are lots of examples of this in the past. I also remember when there were some programs that used incorrect formulas in the CHS <-> LBA translations that created all sorts of compatibility problems. That's why I think it's dangerous to do anything "unique" that no other OS or BIOS does. ------------------------------------------------------------------------------ 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
