Hi all

How do I disable permanently/temporarily copying of files in background? Often while copying many files to usb drive, the message is displayed as 'copying finished'. But when I try to safely remove usb drive, a message pops up like saying 'finishing job... do not unplug usb drive'. And I have to keep looking at the circling animation waiting for it to finish. Some time it takes too long and it is difficult to know whether it hanged or actually doing job in background? Same-thing while copying in terminal too - no difference.

Its same in most of the linux distros I've tried. How do I solve this?

Thanks

When you're copying files to a flash drive or other drive (including your hard drive), they're not actually copied directly to the device byte-by-byte: a buffer is filled and when that's full it's flushed to the device. You don't actually write right away, stuff can sit there in memory for some time -- memory is fast, devices are a lot slower.

Here's a trick: if you're doing a large amount of copying, open a terminal and simply type
and hit the enter key.

That will flush the buffer to the device. You'll notice that there will be a delay while the buffer is written to the device (lights will flash, rain will fall, it'll snow) and, if you repeat the sync it will return almost immediately.

Slow devices (like flash drives) will take a while, a hard drive will take less time but there will be a noticeable delay in either case while the buffer(s) are being written.

Hope this helps some.

2 members found this post helpful.

Whilst perhaps not what you are asking, but may be worth looking up, processes can be brought to the foreground via a terminal & cancelled.

Sync itself is only a suggestion... The kernel doesn't have to do anything in response.

The only way to ensure that buffers are written to a mounted device is to dismount it. That and that alone will ensure the buffers are on disk. If you are copying to a raw device, the only sure way to know if it is finished is if there is an indicator on the device itself.

Normal I/O to a device will be done in about a millisecond. Only if the system is really busy (or the device is slow and there is a lot of data) will writes take longer. That is why dismounting a filesystem is the only way to ensure the writes- a umount has to wait until the filesystem blocks are all updated before the filesystem can be marked as dismounted and removed from the table.

On one system (it wasn't linux though) sync itself did nothing except exit. Its use in scripts was to cause a minor timing delay (caused by loading and executing the code) which gave the system more time to flush buffers anyway, and it made script compatibility easier.

1 members found this post helpful.

Well, a quick look at
indicates
Unmounting will, of course, flush the buffers and update the file system. However, because the sync utility does what it does, execute the sync system call, it seems a little quicker and easier to use rather than unmounting and potentially remounting a device.

Hope this helps some.

Yeah - I've read that. And also the warnings that parallel writes violate that assumption.

The only way to be sure is to dismount the filesystem before you pull the device out.

I'm with jpollard on this.Note it doesn't say immediately.
I always rely on umount.

When blktrace first became available (in beta) I had lots of fun playing with disk I/O - tools like this are quite educational. Fortunately as they develop, better add-ons arrive which make them easier to use.

@tronayne, @jpollard

Many thanks