[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  4469
Date     :  2003-04-28
Author   :  Kan Yabumoto
Subject  :  Re: Clarification on the /CL switch
Size(KB) :  2



Hi all:

One more note on the /CL0 debacle. If you were confused with
my "retraction" of the documentation yesterday, so was I.

Let me retract my retraction. When I found the erroneous
documentation, I decided to correct the problem once for
all and added the new /CA switch which works quite well.

But, my message which I wrote last night after all the
work, I picked up one of the two contradictory help
texts and retracted the wrong one.

The /CL0 explanation was indeed true to what was happening.
It says

/CL0 No cache limit (a file-write always uses cache).

and that was correct and it did the job for profasaurus's
problem as promised in this documentation.

What I was wrong in the documentation was the other help text:

xxcopy /CL /?

which will show the following text:

Cache control -----------------------------
[ ] /CL0 Disables Write-Cache
[x] /CL Sets the Cache-limit (the upper limit for write-cache)
------------------------------------------------------------

Here, it says "/CL0 disables write-cache". This was wrong.
As I pointed out above (and my yesterday's explanation),
/CL0 will remove the upper-limit of the write-cache. That
is, with /CL0, XXCOPY will always enable the write-cache
flag in the CreateFile() call. So, the effect was good.

Anyway, I figured that disabling the write-cache depending
upon the file-size is not a very useful thing. If you
don't want the write-cache, it should be applied to all
cases.

--------------------------------------------------------
After all, trying to prevent the thrashing phenomenon
by the mere manipulation of the FILE_FLAG_WRITE_THROUGH
flag in the CreateFile() function call is a bit too
ambitious (I can't imagine it will have the desired
effect.) I believe when and if your system really
has a disk thrashing problem (which is relatively
rare and rather difficult to ascertain its nature),
the problem should be addressed at the system level
by supplying more space for the virtual memory pool
(increase the allocation to the WIN386.SWP or
PAGEFILE.SYS from the Control-panel).
---------------------------------------------------------

Anyway, this is why we are discontinuing the /CL switch.
Simply put, controlling the write-cache behavior by the
file size was not a good idea (and had a side effect of
causing the unexpected slow file-copy). To characterize
this, it was not a bug at all (except the wrong help
text) --- it was a ill-conceived feature.

But, for backward compatibility's sake, XXCOPY will
continue to accept the /CL switch (/CL to
disable write-cache (same as /CA5) and /CL0 to enable
write-cache unconditionally (same as /CA7) until
everyone forgets what this /CL thing was all about.

Anyway, the new version with the /CA switch should be
more useful. A few more bug fixes were incorporated.
It has been tested all day and it seems good enough for
beta testing.

http://www.xxcopy.com/betatest/ for v.2.84.1

Kan Yabumoto



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.