bug-coreutils
[Top][All Lists]
Advanced

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

bug#6131: [PATCH]: fiemap support for efficient sparse file copy


From: jeff.liu
Subject: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Sat, 17 Jul 2010 10:11:30 +0800
User-agent: Thunderbird 2.0.0.14 (X11/20080505)

Joel Becker wrote:
> On Fri, Jul 16, 2010 at 08:53:27AM -0700, Paul Eggert wrote:
>> I haven't had time to look at it carefully, but here's a very brief
>> review.  The code you sent, like what's in the fiemap branch, has
>> a separate version of a chunk of copy.c that does both reading
>> and writing and optimizes both reading and writing by invoking the fiemap 
>> ioctls
>> at strategic locations.  Instead, it would be better to have
>> a module that separates out the efficient-read stuff by telling
>> copy.c where the next significant input extent is, and then modify copy.c
>> to use that module.  On hosts that do not support fiemap, the module
>> would simply report the entire input file as that file's only extent.
> 
>       Precisely.  The sparse-core.c or whatever it is called shouldn't
> be doing the copy, it should just provide:
> 
> handle = init_extent_scan(fd);
> while (get_next_extent(handle, &extent_start, &extent_len)) {
>     ...
> }
> close_extent_scan(handle);
> 
>       Then copy.c just implements this loop and the '...' part.
> 
> Joel
> 

yes, its better to separate copy and extent scan, and its not difficult to 
implement.  But I was
wondering to return an array of extents info or just return one extent info for 
each scan?

I would like to work out an unique interface could work for both Linux and 
Solaris, for Solaris
SEEK_DATA/HOLES stuff, looks its convinent to just return next extent info 
every time.

But for fiemap, maybe its better to return an extents_info_array as currentt 
design to reduce the
ioctl(2)  calls.

 union { struct fiemap f; char c[4096]; } fiemap_buf;
 enum { count = (sizeof fiemap_buf - sizeof *fiemap) / sizeof *fm_ext };

Maybe we can encapsulae Solaris SEEK_DATA/SEEK_HOLE to return 
extents_info_array(if possible, not
play with those APIs yet) if you guys aggree with above.

then Joel's code example looks like:
handle = init_extent_scan(fd);
while (get_next_extents(handle, &extents_info)) {
    num = extents_info->extents_count;
    for (i = 0; i < num; i++)
      {
        extent_info = extents_info[i];
        same_as_usual;
      }
}
close_extent_scan(handle);



Thanks
-Jeff



-- 
The knowledge you get, no matter how much it is, must be possessed yourself and 
nourished with your
own painstaking efforts and be your achievement through hard work.





reply via email to

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