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

Number   :  4544
Date     :  2003-05-06
Author   :  profasaurus
Subject  :  Re: Clarification on the /CL switch
Size(KB) :  3


Awesome, thanks Kan for the interesting read and fix!

--- In xxcopy@yahoogroups.com, Kan Yabumoto  wrote:
> 
> 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.