Hi Marton,

CCing the kernel list about this issue... Merry Xmas everybody :-).

> the FreeDOS PC it is painfully SLOW! (100kb/sec)

How fast is it with other DOS?

> 1) If I connect FROM the FreeDOS PC to the other PC to copy the files,
> it flies! (~3MB/sec)

Wow, that is a lot better :-).

> 3) If I copy the files to a RAM Drive instead of, say the drive C:,
> it flies also so I believe that

> a) FreeDOS has some ... issue writing to the hard-disk "in background"
> (which is what happens when you copy files from another PC to it)

Maybe you tried this on a large fat32 disk? I think our FAT
writes can be pretty slow in such a context. You can also try
using a delayed-write cache. LBAcache does not delay writes.

It might also help to first set the file size to the final
size without actually filling the contents yet. If you want
to experiment with that, I could make a modified XCOPY for
you, so you can compare local XCOPY speed of normal and
modified XCOPY versions :-).

To get a small write improvement, try the udma/udma2, xdma, qdma
or uide driver from Jack (whichever version is online at the
moment) and enable the write overlap. That means that DOS can
already do other stuff after sending the data to the disk,
without waiting for the okay from the disk.

For real delayed / pooled write caching, try DR DOS nwcache or
a shareware cache like the ones mentioned as "delayed write"
or "write combine" in caches.txt in docs/lbacache/ :-). Those
are: Quickcache, Hyperdisk, Ccache, I_Cache. If one of those
makes writing significantly faster with MS Client, I would be
very happy if you could help me with some experiments! Let me
know if you have problems to find those caches online...

> If I do ANY operation to the disk, say, read a directory for example, I
> get a "PANIC: more than two near fnodes requested at the same time!"

Hmmm I did not know that you are supposed to be allowed to do
several file operations simultaneously. You cannot disable the
warning, you have to provide more near f_nodes ;-). Otherwise
you get unpredictable results.

You will have to change only two places...

get_near_f_node() in fatfs.c, change to, for example:

f_node_ptr get_near_f_node(void)
  int n = 0;
  f_node_ptr fnp = fnode;
  while (n<4) {
    if (fnp->f_count == 0) {
      return fnp;
  panic("more than 4 near fnodes requested at the same time!\n");
  return (f_node_ptr) 0;

You also have to change the last 2 lines in globals.h, in the SDA:

GLOBAL struct f_node fnode[4];
GLOBAL int fnode_fd[4];

I guess that MS Client would be supposed to swap out the SDA or
to avoid kernel reentrancy by just not calling the kernel while
the kernel is already busy. But I do not know any technical MS
Client details so giving FreeDOS more near f_nodes is worth a
try. They are sort of "short term working memory" for FreeDOS.


PS: Try loading the doslfn driver before you load lfnsort ;-) You
may also want to use a FAT32 enabled kernel or set VERSION=7.10 ...

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Freedos-user mailing list

Reply via email to