Personal computing discussed
Moderators: renee, Flying Fox, Ryu Connor
maxxcool wrote:You are seeing disk cache burst and not windows cache burst.
Forge wrote:I think Maxxcool is indicating that the 4GB of super-speed transfer simply isn't happening. The disk cache gobbles the first tiny piece of the transfer so quickly that Windows projects the entire transfer at that speed, and then requires multiple uncached transactions before it revises the estimate downward.
OP wrote:80% of the file "appears" to copy over in 2 seconds or so
just brew it! wrote:So it is more than just projected completion time. *Something* is gobbling up the first few GB of the file rather quickly, and the OS's file cache is the only logical place it could be going.
just brew it! wrote:How much RAM is available to to the OS? (I.e. how much of that 32GB is allocated to the ramdisk?)
jmc2 wrote:8Gigs to W7 and 24 to the Ram drive.
just brew it! wrote:Forge wrote:I think Maxxcool is indicating that the 4GB of super-speed transfer simply isn't happening. The disk cache gobbles the first tiny piece of the transfer so quickly that Windows projects the entire transfer at that speed, and then requires multiple uncached transactions before it revises the estimate downward.OP wrote:80% of the file "appears" to copy over in 2 seconds or so
So it is more than just projected completion time. *Something* is gobbling up the first few GB of the file rather quickly, and the OS's file cache is the only logical place it could be going.
just brew it! wrote:jmc2 wrote:8Gigs to W7 and 24 to the Ram drive.
Well I'll bet that's your issue right there. Windows isn't going to use *all* of the RAM available to it for write-behind cache. The OS itself and the working sets of any applications you're running all take up RAM, and the OS also keeps some percentage of the RAM in reserve to meet short-term demand.
My suggestion is to try dropping the size of the RAM disk to 20GB and see if that has an effect.
I think Maxxcool is indicating that the 4GB of super-speed transfer simply isn't happening. The disk cache gobbles the first tiny piece of the transfer so quickly that Windows projects the entire transfer at that speed, and then requires multiple uncached transactions before it revises the estimate downward.
Regardless, I don't think anyone here really has a solid handle on what the file transfer dialog is really saying. I know I've seen the same results on my big ram machines (16+ GB), and I've done some pondering, with no clear conclusions.
Ryu Connor wrote:If you have enough RAM, SuperFetch will cache entire large file transfers and then finish writing them to the disk in the background.
Ryu Connor wrote:If you fear data loss an UPS is pretty much a prerequisite regardless of your file transfer methods.
Ryu Connor wrote:A move wouldn't - typically - require such backfilling unless you're transitioning between partitions or disks.
just brew it! wrote:And since we're talking about a RAMDisk, concerns about delayed writes are the least of your reasons to be considering a UPS.True; however, to get back to the OP's situation, he is taking a large file that has been staged to a ramdisk for processing, and copying it back to permanent storage. So by definition it is going to a different "disk".
Captain Ned wrote:Honestly, the first time I read that I missed the word "suit" entirely.If I wore suit pants I'd probably go belt & suspenders.
Ryu Connor wrote:If you have enough RAM, SuperFetch will cache entire large file transfers and then finish writing them to the disk in the background.
Ryu Connor wrote:That setting is very dangerous without an UPS. It lets the hard drive manage when data is actually written to the disk from the disk buffer. A power outage could result in substantial data loss (64MB on modern disks).
A shutdown does flush the buffer to disk.
jmc2 wrote:You shouldn't draw any conclusions from this. The OS won't reclaim the memory immediately (unless there is severe memory pressure, in which case you wouldn't see it return as available at all since something else would be gobbling it up). The memory manager shuffles pages between the various lists on a background thread, so you can't infer anything from the speed it goes back to being available. You really need to look at IO rather than memory if you're trying to figure when the transfer is "done"The "file copy bar" is gone in 13 seconds but the available memory
takes 30 something seconds to recover.