[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.