Hi all, can anybody tell me if LBAcache now handles over-formatted floppy disks properly? As you know, you can use FreeDOS FORMAT (or Linux tools or whatever else you prefer) to format e.g. to 1680k in an 1440k drive. In the past, LBAcache bailed out when you had LBAcache FLOP loaded and tried to use such a disk. For testing, you can load from the prompt:
LBAcache DRV NULL BUF 8 FLOP (drv null suppresses harddisk caching if you have a problem with it, the NORMAL way to use LBAcache would be no DRV ... option at all, letting LBAcache autodetect the harddisks) LBAcache should update geometry properly if you start using a 1680k floppy after loading it, and it should detect the size change even if you re-format a 1440k floppy to 1680k while LBAcache is loaded. So far for the theory. Alas you need a real floppy drive, a free floppy disk and a FreeDOS kernel (FreeDOS has the nice feature of being able to use special formats without extra drivers) for this test and I do not have all of that around right now :-(. http://www.coli.uni-sb.de/~eric/stuff/soft/ lbacache-14apr2004.zip Changes: Floppy stuff described above, reduced panicking (now ignores geometry change function 18 for drives 2..7f/88..ff and ignores Con->Fmt function 0xec), improved startup message (no longer quotes the command line, better and redirectable feedback message for DRV option), using 8k instead of 4k element size now (-> only 35k DOS RAM used for 29 MB cache size, although such huge caches are NOT recommended). Maybe other small changes which I forgot to mention. I hope the element size change did not introduce new bugs. If you can test LBAcache with more than a floppy (e.g. test it with a real or virtual harddisk) on a test system where data loss is no problem, please do so. My own test system is not available today, sorry. A very interesting question is whether the bigger element size reduces the cache hit ratio in real life situations (whatever your preferred test is, maybe something like compiling the FreeDOS kernel). If YES, I would add a command line option to select element sizes of 1 / 2 / 4 / 8 kilobytes (similar to SMARTDRV). If NO, I would just leave LBAcache compiled to maximum element size of 8k (as it is now, similar to NWCACHE). Comparison is simple: Run the test with LBAcache 22oct2003 (4k element size) once and run it again with LBAcache 14apr2004 (of course with a strategy like 1. make clean 2. LBAcache sync 3. make 4. LBAcache info to have reproduceable reaults). The bigger element size will also lower CPU load -> improve disk access speed in case of cache miss. However, I hope to find the time to improve cache miss response speed a lot by changing binsel2.asm findbin algorithm soon anyway. Would be good if somebody could test the 14apr2004 version SOON to allow Bernd to include it in the next FreeDOS beta 9 release candidate. Thanks! (Pity that my own test system is not ready soon enough...) Eric ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
