Hi developers!
Looking at the source code of the GRUB4DOS version of the ELTORITO.SYS driver, I realized that there is a risk of breaking EL TORITO access to CD content by using LBACACHE. Is there anybody with a suitable "CD authoring toolchain" who could test my theory? The El Torito way of booting from CD/DVD lets the boot loader tell the BIOS (int 13.4a to int 13.4d) that part or whole of the booted CD/DVD should be used to create a fake BIOS drive. With floppy or harddisk images, this is safe for LBACACHE: A boot loader tells the BIOS which CHS geometry and size should be created from the boot image and on which drive number and LBACACHE will treat it as if it was a real drive and cache that smoothly. The problem is that you can also use a raw mode or NON-EMULATION mode: There, the WHOLE CD/DVD will be made visible as if it would be a harddisk with 2048 byte sector size. This makes it very easy for the ELTORITO.SYS driver to use only int 13.4b01 (status, to detect suitable drives, alternatively just test-reading sectors 16 and 17, which it also does after int 13.4b01 to be on the safe side) and int 13.42 (LBA sector read) to present the CD/DVD to normal DOS MSCDEX or SHSUCDX, of course without any special features such as audio etc. Now if LBACACHE tries to cache that sort of drive (it only checks int 13.08 to get size and geometry) it will blindly assume that sector size is 512 and if you read 2 sectors from the CD, it will put the first 1024 bytes of the first sector in the cache and believe that it has cached both sectors in full. When you later encounter a cache hit, it will give you this fraction of the data and believe that this was enough to make the actual disk access unneeded, so your view of the CD/DVD contents will, according to my worries, be totally scrambled. So if somebody has the tools to create El Torito non-emulation mode bootable CD, please test whether things are as bad as I fear they are. This means the CD has to be booted using ISOLINUX and MEMDISK with a non-El Torito (MEMDISK instead of BIOS) boot disk image, if I am not mistaken, while activating the ELTORITO.SYS driver later during boot. My question is: If you boot in that way, what will the LBACACHE cache say about the virtual, 2048 byte per sector "harddisk" representing the whole CD? Will it actually try to cache it? And if yes, are my worries correct that trying to read the same files from CD twice will result in the second read returning nonsense contents, while at least not causing overflows in LBACACHE itself? Still bad enough to return wrong contents, of course! When you start LBACACHE, it will show geometries (only heads and sectors-per-track) for all drives it tries to cache. When you later run LBACACHE INFO, it will tell you about the interrupt vectors, size of XMS and overall I/O statistics including cache hits and misses, without mentioning how many were related to which drive. Still, knowing whether LBACACHE tries to cache the "harddisk" which in reality is the proxy to the CD and knowing whether this results in data loss will be possible. LBACACHE could work around the problem by using int 13.48 (only if the BIOS supports that...) or by test-reading one sector per drive to find out how large sectors are, then skip caching drives with sector sizes other than 512 bytes. Note that because FreeDOS cannot work with drives with visibly 4096 bytes per sector, modern real SSD or harddisk can FOR THE MOMENT be expected to be in 512 byte per sector mode, but this is yet another future risk which will break LBACACHE. In the meantime, I recommend UHDD caching, because that already does use int 13.48 and other functions to gather detailed information about each drive to decide which drives can be cached and/or use UDMA. It feels very strange that LBACACHE could have been breaking ELTORITO.SYS for more than 10 years without anybody noticing, so maybe my worries are based on some mistake. Unfortunately, we do not use a cache at all in the current installer, but we have, as far as I remember, used caches in some older installers. I strongly recommend using a cache, of course one which does NOT break ELTORITO.SYS, in ALL installer activities, because that gives you big speed gains! So again, if you have the tools to create a bootable ISOLINUX, MEMDISK, FreeDOS, LBACACHE and ELTORITO.sys ISO and test what happens when you boot that, please do that and let me know what happened in reality. Thank you for testing! Regards, Eric PS: Any experiences with int 13 function 50 for USB or FireWire "packet command" BIOS support? _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
