I have got reports from our team members that DOpus occassionally freezes on writing large files to USB-Sticks. All these systems have a huge amount of memory (>= 32GB). I thought that's pretty easy to fix by enabling non-buffered-IO copying mode in the preferences. But after having a look to these systems all of them still have this feature enabled.
I made further analysis and it looks as DOpus doesn't flag the write operations in non-buffered-IO mode as un-cached (write-through). Only the read operations are flagged as expected.
I copied a 5 GB file to an USB-Stick and after the copy dialog disappeared the stick was still blinking for 1-2 minutes. It looks as the write cache of the filesystem was filled during writing and needed to be flushed to the stick. During this time the stick was nearly unusable (each access took 10-20 seconds) and DOpus showed the busy cursor.
I copied the same file by using xxcopy (with /CA0 to disable write caching) and the actual copy operation took much longer but after the command returned the USB-Stick instantly stopped blinking. During this time the stick was still accessable by DOpus (no freezes at all).
I had a short look to process-monitor filtering the write operations out:
Copy using DOpus with enabled non-buffered-IO
-> Filesystem write cache is filled and system is occassionally freezing until USB-Stick stops blinking
Copy using xxcopy with disabled write-caching (/ca0 parameter)
-> Copy took longer but no freezes at all (USB-Stick stops blinking when command returns)
Copy using xxcopy with enabled write-caching (/ca7 parameter)
-> Filesystem write cache is fille and system is occassionally freezing until USB-Stick stops blinking
Is it possible to flag the write operations to be uncached (write-through) when using DOpus non-buffered-IO mode to behave in a similar way as xxcopy /ca0 mode? This would improve the responsibility of the overall system and allows the user to keep on working with the USB-Stick.
The problem is probably triggered by having non-buffered I/O turned on. If you turn it off I expect the problem will go away.
Some USB devices, firmware or drivers (we're not sure which) do not handle non-buffered I/O properly. This is why we disabled it by default. (Your screenshot must be from an old version, as it shows it is enabled by default.)
If you want to use non-buffered I/O for some devices and not others, you can do so using a script.
In the last years we all have used non-buffered I/O turned on since it seems to be much more compatible with our virus scanner (company standard). If I turned it off our systems start to freeze when copying thousands of files (e.g. subversion repository) from SSD to SSD. Thus for our use-cases non-buffered I/O seems to help a lot and we haven't had any actual problems yet.
Anyway if I turn it off on my own system (SSD and a lot of RAM) many file operations begins to stutter and the whole DOpus user-interface isn't that responsible anymore. Thus I would prefer to keep it enabled if at all possible.
Do you know why the DOpus write operations in non-buffered I/O mode are not using write-through mode? I assume this decision was made by intention? I would expect that in non-buffered I/O both operations (reading and writing) are performed uncached? But it looks as only the reading is performed uncached. Is it just a matter of providing some mode flags to let the writing be uncached as well? Can we give that a try?
Direct comparison of the xxcopy unbuffered write and DOpus unbuffered write seems that xxcopy flags the write as synchronous write-through. And in this mode we can copy hundreds of gigabytes without any issues.
Some part of your seems to have problems with file I/O. None of the buffering or write-through flags should make as much difference as they are on your system, so something is wrong with it. I could not say where the problem is from here.
We won't be modifying the way Opus copies files any further to fix issues that only occur on your system. Any changes we make for one system are likely to cause problems on lots of others, and we have to do what's best for everyone. The buffered I/O code we added for you ended up using up a lot of our development, testing and support time, and probably wasn't worth it in the end as the benefits most people saw were small, and a large enough number of people ran into problems with USB devices (which tend to be sensitive to anything except vanilla I/O) that we ended up disabling it by default, such that almost zero people are now benefiting from it.
Working out why your system freezes under I/O load and fixing it is the best course of action, and not something we can do as we don't have access to your systems.
In your answers, I often have the feeling that you expect that we should check before the opening of a posting whether other users are affected as well to find out if our issue is of global interest. That's kind of impossible. We report problems, you decide on the action, we live with it. That is the usual way and we are happy with that. Anyway I have often a bad conscience, because I think that my questions annoy you. You can be certain that this is not our intention and we are worry about that.
[quote="leo"]
Working out why your system freezes under I/O load and fixing it is the best course of action, and not something we can do as we don't have access to your systems.[/quote]
Actually I've done a lot of analysis to find out why DOpus is freezing (before writing my posting). And the apparent reason for this behavior is that with a large amount of free memory (> 20GB) Windows decides to buffer a lot of file content if any application is writing tons of data unbuffered. I can reproduce the same behaviour with other applications on different systems haveing such large amount of RAM.
The issue could be fixed instantly for all applications, that allow to manually enable unbuffered I/O (e.g. like the /ca0 flag for xxcopy). Only DOpus non-buffered I/O mode seems not to fix that. Thus I have had a deeper look and it seemes to be contradictional that DOpus writes content buffered if the unbuffered mode is enabled. That was the moment, when I decided to report it.
Certainly I hoped it could be fixed by just adding a flag to the DOpus write algorithm but if only we are affected I understand it's not worth the effort.
PS: I guess it depends on our unusual system configuration. Copying from a SSD-RAID (providing 1,2 GB/s) on a machine with 29 GB free memory and writing to a USB2 stick with 30 MB/s will confuse the caching mechanisms.
