LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   How to disable background copy? (https://www.linuxquestions.org/questions/linux-newbie-8/how-to-disable-background-copy-4175540702/)

bangnagr 04-25-2015 06:25 AM

How to disable background copy?
 
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

tronayne 04-25-2015 06:44 AM

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
Code:

sync;sync;sync
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.

fatmac 04-25-2015 06:55 AM

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

jpollard 04-25-2015 08:42 AM

Quote:

Originally Posted by tronayne (Post 5352849)
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
Code:

sync;sync;sync
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.

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.

tronayne 04-25-2015 10:34 AM

Well, a quick look at
Code:

info coreutils 'sync invocation'
indicates
Quote:

`sync' writes any data buffered in memory out to disk. This can
include (but is not limited to) modified superblocks, modified inodes,
and delayed reads and writes. This must be implemented by the kernel;
The `sync' program does nothing but exercise the `sync' system call.

The kernel keeps data in memory to avoid doing (relatively slow) disk
reads and writes. This improves performance, but if the computer
crashes, data may be lost or the file system corrupted as a result.
The `sync' command ensures everything in memory is written to disk.

Any arguments are ignored, except for a lone `--help' or `--version'
(*note Common options::).

An exit status of zero indicates success, and a nonzero value
indicates failure.
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.

jpollard 04-25-2015 11:47 AM

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.

syg00 04-25-2015 07:07 PM

I'm with jpollard on this.
Quote:

The `sync' command ensures everything in memory is written to disk.
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.

bangnagr 04-26-2015 02:50 AM

@tronayne, @jpollard

Many thanks


All times are GMT -5. The time now is 08:10 AM.