[Top][All Lists]

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

Re: [coreutils] Feature: Introduce fiemap copy to cp(1) and mv(1) v2

From: jeff.liu
Subject: Re: [coreutils] Feature: Introduce fiemap copy to cp(1) and mv(1) v2
Date: Fri, 09 Apr 2010 23:46:12 +0800
User-agent: Thunderbird (X11/20080505)

Pádraig Brady wrote:
> On 09/04/10 14:41, jeff.liu wrote:
>> Hello All,
>> Please ignore the previous patchsets, there is an issue I just fixed.
>> The revised version were shown as following:
>> From: Jie Liu <address@hidden>
>> Date: Fri, 9 Apr 2010 21:31:27 +0800
>> Subject: [PATCH 1/2] Add fiemap.h for fiemap ioctl(2) support.
>> diff --git a/src/fiemap.h b/src/fiemap.h
>> new file mode 100644
>> index 0000000..d33293b
>> --- /dev/null
>> +++ b/src/fiemap.h
> I guess we should emulate this only when fiemap.h is not available
For now, I do check as below,

# include "fiemap.h"

>> +# include <linux/types.h>
> The emulation should not need the above #include
Thanks for pointing this out.

>> From: Jie Liu <address@hidden>
>> Date: Fri, 9 Apr 2010 21:38:23 +0800
>> Subject: [PATCH 1/1] Add fiemap copy for cp(1).
>>  This feature is intended to for optimization of backup sparse files.
>> Fiemap copy can be trigger via 'cp --fiemap=[WHEN]', if 'fiemap=auto' 
>> specify and
>> the underlying FS does not support FIEMAP or fiemap copy failed, fall back to
>> normal copy.
> I'm not convinced this feature needs any options.
> I.E. any reason for not always trying this and falling back if not possible?
At first, I only consider to optimize the sparse file copy with the benefits of 
fiemap (i.e., avoid
examining holes).

If this feature does not affect the cp(1) semantics, maybe we can always do 
fiemap copy.

I have done some tests, the performance of fiemap copy is pretty much the same 
thing by comparing to
the normal copy for the regular files.

> cheers,
> Pádraig.


reply via email to

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