5 ms·

Ugh. So, instead of tackling something like auto-queuing of copy operations to prevent disk thrashing, they did the 'hard' work of adding a pause button and so

Ugh. So, instead of tackling something like auto-queuing of copy operations to prevent disk thrashing, they did the 'hard' work of adding a pause button and some silly bling. Incidentally, if that conflict-resolution dialog doesn't provide mouse-over image enlargement/preview, I'm going to instantly hate it.

sjs 15y ago
People who are serious about this stuff just use TeraCopy on Windows anyway. Who wants to copy terabytes or even gigabytes of data and not verify it? People who build systems, in general and excluding the ZFS authors, really need to start worrying about my data's integrity at least as much as I do.
- sjwright 15y ago
  I used to use TeraCopy, but on my Windows 7 64 bit machine, it's half the speed of the built-in copy for network transfers. It's fairly clear that Windows is doing a significantly better job with buffering. I still keep TC around for the odd job, but it's no longer my default.
  - sjs 15y ago
    Ouch. That's good to know. Through sheer luck till now I've mostly done network transfers using smb + rsync on my notebook.
acqq 15y ago
Yes, from their example ("pausing" one task speeds up the rest, and graphs show speed progress "hills and valleys") it can be concluded that they let copy tasks run in parallel instead of queuing the files. That's practically a guaranteed way to produce more fragmented disk layouts. Well done, current MSFT programmers. You understand what's going on in MSFT when the blog post ends with the line like "All of this adds up to building a significantly improved copy experience, one that is unified, concise, and clear, and which puts you in control of your experience." A clear example of managerspeak -- adjusted to sound good among other managers not to mean something.You see even from where the battles for "bling" come.
- michael_dorfman 15y ago
  That's practically a guaranteed way to produce more fragmented disk layouts. Well done, current MSFT programmers. Is disk fragmentation a serious problem for you? I use SSDs for most of my drives, and let the Microsoft defragger do its thing once in a while, and leave it at that. Doesn't seem to bother me none.
  - nodata 15y ago
    You're not supposed to defrag an SSD with Microsoft defragger, are you really doing that?
    - mafro 15y ago
      Do you have a reference for this info?
      - acqq 15y ago
        http://www.micro-isv.asia/2010/12/never-defragment-an-ssd/ http://www.micro-isv.asia/2010/12/never-defragment-an-ssd/ "The key benefit to SSDs is that they have virtually no seek time. Reading adjacent blocks of data is no faster than reading blocks that are spread out over the drive. Fragmentation does not affect SSD drive speed. (...) SSD drives physically wear out as you write to them. Defragmentation software moves around all the files on your drive. Thus, defragmenting an SSD reduces its life span without giving you any benefits."
        starwed 15y ago
        I had an old netbook with an SSD. A lot of folk noticed that the performance of the disk got slower over time. Surprisingly, defragging the drive actually improved the performance -- but IIRC it was a side effect of the process, not directly anything to do with fragmentation. I don't quite remember what the issue was, but there was a good anandtech article about it: http://www.anandtech.com/show/2738/8 http://www.anandtech.com/show/2738/8 Fairly certain modern SSDs are not affected, in any case.
dspillett 15y ago
Auto-queueing is not an no-brainer. While it is easy to assess which operations will contend with each other on local drives as soon as you start interacting with the network it gets far more fluffy as the storage arrangement is abstracted away from where the local OS can detect it. Even for local operations automatically queueing operations could be sub-optimal. If copying chunks for small files from two spinning-disk-and-moving-heads drives to an SSD basic queuing algorithms would perform one copy after the other but the SSD is probably more than capable of keeping up with both at the same time. So you are going to need a UI control to override the default queuing. BTW: If you need auto-queuing and other tweaks in this area for current Windows variants, I've been using the free (not Free) version of http://en.wikipedia.org/wiki/Teracopy http://en.wikipedia.org/wiki/Teracopy for some time and have found it to be useful and reliable. One thing I would love to see in a conflict resolution dialog is the option to view a diff of text files and similar, like Debian offers to help resolve file conflicts when applying package updates, not just previews of graphics files.

sjs 15y ago

People who are serious about this stuff just use TeraCopy on Windows anyway. Who wants to copy terabytes or even gigabytes of data and not verify it? People who build systems, in general and excluding the ZFS authors, really need to start worrying about my data's integrity at least as much as I do.

sjwright 15y ago
I used to use TeraCopy, but on my Windows 7 64 bit machine, it's half the speed of the built-in copy for network transfers. It's fairly clear that Windows is doing a significantly better job with buffering. I still keep TC around for the odd job, but it's no longer my default.
- sjs 15y ago
  Ouch. That's good to know. Through sheer luck till now I've mostly done network transfers using smb + rsync on my notebook.

acqq 15y ago

Yes, from their example ("pausing" one task speeds up the rest, and graphs show speed progress "hills and valleys") it can be concluded that they let copy tasks run in parallel instead of queuing the files. That's practically a guaranteed way to produce more fragmented disk layouts. Well done, current MSFT programmers. You understand what's going on in MSFT when the blog post ends with the line like "All of this adds up to building a significantly improved copy experience, one that is unified, concise, and clear, and which puts you in control of your experience." A clear example of managerspeak -- adjusted to sound good among other managers not to mean something.You see even from where the battles for "bling" come.

michael_dorfman 15y ago
That's practically a guaranteed way to produce more fragmented disk layouts. Well done, current MSFT programmers. Is disk fragmentation a serious problem for you? I use SSDs for most of my drives, and let the Microsoft defragger do its thing once in a while, and leave it at that. Doesn't seem to bother me none.
- nodata 15y ago
  You're not supposed to defrag an SSD with Microsoft defragger, are you really doing that?
  - mafro 15y ago
    Do you have a reference for this info?
    - acqq 15y ago
      http://www.micro-isv.asia/2010/12/never-defragment-an-ssd/ http://www.micro-isv.asia/2010/12/never-defragment-an-ssd/ "The key benefit to SSDs is that they have virtually no seek time. Reading adjacent blocks of data is no faster than reading blocks that are spread out over the drive. Fragmentation does not affect SSD drive speed. (...) SSD drives physically wear out as you write to them. Defragmentation software moves around all the files on your drive. Thus, defragmenting an SSD reduces its life span without giving you any benefits."
      - starwed 15y ago
        I had an old netbook with an SSD. A lot of folk noticed that the performance of the disk got slower over time. Surprisingly, defragging the drive actually improved the performance -- but IIRC it was a side effect of the process, not directly anything to do with fragmentation. I don't quite remember what the issue was, but there was a good anandtech article about it: http://www.anandtech.com/show/2738/8 http://www.anandtech.com/show/2738/8 Fairly certain modern SSDs are not affected, in any case.

dspillett 15y ago

Auto-queueing is not an no-brainer. While it is easy to assess which operations will contend with each other on local drives as soon as you start interacting with the network it gets far more fluffy as the storage arrangement is abstracted away from where the local OS can detect it. Even for local operations automatically queueing operations could be sub-optimal. If copying chunks for small files from two spinning-disk-and-moving-heads drives to an SSD basic queuing algorithms would perform one copy after the other but the SSD is probably more than capable of keeping up with both at the same time. So you are going to need a UI control to override the default queuing. BTW: If you need auto-queuing and other tweaks in this area for current Windows variants, I've been using the free (not Free) version of http://en.wikipedia.org/wiki/Teracopy http://en.wikipedia.org/wiki/Teracopy for some time and have found it to be useful and reliable. One thing I would love to see in a conflict resolution dialog is the option to view a diff of text files and similar, like Debian offers to help resolve file conflicts when applying package updates, not just previews of graphics files.