Hi Tom,

>>> More tests: http://jafile.com/uploads/dos386/perftest.txt
> unless dos386 describes what program(s) he used on what hardware
> to produce these results, the data are useless :(
>> ...you can try first writing some dummy data at where the file
>> will end, then close it and re-open (without truncate of course)
>> and do the actual copy. That should bundle the FAT updates and
>> increase performance significantly :-)
> just did exactly this (for command.com) COPY.
> unfortunately performance remains the same.
> for a single drive (that is able to read ~43 MB/sec), using
> a copy buffer of 60K (Freecom default), copy performs
> roughly identical, even if the file is pre-created.

Please explain. You compiled a modified version of the built-in
COPY command of command.com? My suggestion was to pre-grow the
file, not only pre-create it. Something like, ca 2 GB example:

- open and create a new file for writing
- seek to offset ca 2 GB (works even though file is still empty)
- write 1 byte of data at this place
- close the file

(this should allocate all clusters for a full 2 GB file in FAT)

- open file for writing (no truncate)
- file is now 2 GB but data is "random" contents of whatever
  was in the before-unused clusters unless your kernel was
  compiled with WRITEZEROS (normally not the case)
- write 2 GB of normal data to the file in big chunks,
  preferrably with a copy buffer not wrapping a linear 64 kB
  offset and with a size which is a multiple of 1 cluster.

(should only have to write data, FAT unchanged, few seeks,
in particular if FAT data can use BUFFERS or a read cache)


PS: http://jafile.com/uploads/dos386/perftest.txt says the
test involves R/W of one file of 2'400'000'000 Bytes but it
does not specify which int21 functions or tools were used.

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
Freedos-kernel mailing list

Reply via email to