home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.msdos.programmer
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewse!cbnewsd!att-out!cbfsb!cbnewsg.cb.att.com!rnichols
- From: rnichols@cbnewsg.cb.att.com (robert.k.nichols)
- Subject: Re: Fast floppy writing techniques
- Message-ID: <1992Sep11.195112.23171@cbfsb.cb.att.com>
- Summary: Smartdrv can help -- if you're bold enough to use it
- Sender: news@cbfsb.cb.att.com
- Organization: AT&T
- References: <BuF2p7.CBC@DMI.USherb.CA>
- Date: Fri, 11 Sep 1992 19:51:12 GMT
- Lines: 30
-
- In article <BuF2p7.CBC@DMI.USherb.CA> famus2@DMI.USherb.CA (Projet2 Famus) writes:
- >Hi, I was wondering if anyone has C code for fast file writing to floppies.
- >The application that I'm writing compresses the data before writing to disk,
- >but the bottleneck is the floppy. I'm currently trying to optimize disk
- >writing by using a technique similar to XCOPY, but if I had code that
- >resembled XCOPY already written that might help me meet my deadline.
- ...
-
- Enabling SMARTDRV's write-behind cache for the floppy drive can
- give dramatic improvement. BUT, you have to be brave and bold to
- try it, and careful enough not to snatch the floppy from the drive
- as soon as you application thinks it's done, because SMARTDRV may
- still be writing for a while.
-
- I often do this ("smartdrv a+") when copying a large number of files
- to a floppy. It saves all the seeking back and forth between the
- directory and the user data area. With 2MB of cache (when not in
- Windows), the copy operation runs at the speed of the hard drive and
- completes; the floppy is still tick, tick, ticking along writing tracks
- as fast as possible. I wait for a "smartdrv /c" to return before
- removing the floppy, and all is well. (I also do a "smartdrv a" to get
- back into a safer mode.)
-
- It should be possible to get this behavior from within an application,
- but I know of no other way than loading and executing SMARTDRV with
- the apropriate parameters, and a large app. probably wouldn't have
- enough memory available to do this.
-
- Bob Nichols
- rnichols@ihlpm.ih.att.com
-