Login  Register

Re: Issue with progress bar and locking files when saving

Posted by Stein Rørvik on Sep 24, 2020; 7:33am
URL: http://imagej.273.s1.nabble.com/Issue-with-progress-bar-and-locking-files-when-saving-tp5023969p5023971.html

Fred,

My USB disk is formatted as NTFS and is not regarded as a removable in the disk manager, so I cannot turn the caching on or off by any simple means. I assume the caching is always on. I agree to your suggestion that because of the disk caching, "the throughput appears better than it really is". It makes sense that when the file close request is sent by ImageJ, it is not honored until the file is actually residing on disk.

For USB disks I have always used "configure for performance" when that choice is available, and used the "safely remove media" icon to make sure that the cache is flushed. If the disk is accidentally removed while writing (for example if the disk is moved in a way that causes it to disconnect), the last written file is usually corrupt. Fortunately, the Windows disk repair feature is able to fix the file system errors that occur in these cases, so that we can re-write the file safely.

Stein

-----Original Message-----
Sent: 23. september 2020 01:37
Subject: Re: Issue with progress bar and locking files when saving

Greetings Stein,

Most likely your USB disk is configured for performance. In this case, the write to disk requests are cached by the OS and the throughput appears better than if really is.  Most likely the close file request waits until the cache has made it to disk.  This is configurable in the low level system IO calls.  For USB drives you can configure for safe physical removal, and the write requests will wait until the cache has made it to disk; this will appear to work the way that you think it should.

Most drives are configured for performance, and thus why you should not dop a hard shut off of you computer. The "remove device" icon on windows and the /bin/sync command are there for insuring all the cache is flushed to the physical disk.

Fred

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html