coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: new cp option: --efficient-sparse=HOW


From: Pádraig Brady
Subject: Re: RFC: new cp option: --efficient-sparse=HOW
Date: Tue, 01 Feb 2011 01:35:29 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 31/01/11 21:46, Jim Meyering wrote:
> Now that we have can read sparse files efficiently,
> what if I want to copy a 20PiB sparse file, and yet I want to
> be sure that it does so efficiently.  Few people can afford
> to wait around while a normal processor and storage system process
> that much raw data.  But if it's a sparse file and the src and dest
> file systems have the right support (FIEMAP ioctl), then it'll be
> copied in the time it takes to make a few syscalls.
> 
> Currently, when the efficient sparse copy fails, cp falls back
> on the regular, expensive, read-every-byte approach.
> 
> This proposal adds an option, --efficient-sparse=required,
> to make cp fail if the initial attempt to read the sparse file fails,
> rather than resorting to the regular (very slow in the above case) copy
> procedure.
> 
> The default is --efficient-sparse=auto, and for symmetry,
> I've provided --efficient-sparse=never, in case someone finds
> a reason to want to skip the ioctl.

I'm 50:50 on whether we should add this option.
If a user doesn't want to copy the file if it's going
to be too slow, then what other options do they have?
Also the sparseness of a file can change over time.

Given the fairly specialized need for such an option,
perhaps it's best to foist to other tools, like:

test $(du f) -lt $limit && df -T -t myfs f && cp f f2

or perhaps

timeout $time_limit cp f f2 || { rm f2; echo "oops" >&2; }

cheers,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]