[Top][All Lists]
[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.
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, jeff.liu, 2010/07/14
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Pádraig Brady, 2010/07/14
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Paul Eggert, 2010/07/14
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Pádraig Brady, 2010/07/14
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, jeff.liu, 2010/07/14
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Paul Eggert, 2010/07/15
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, jeff.liu, 2010/07/16
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Paul Eggert, 2010/07/16
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Joel Becker, 2010/07/16
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy,
jeff.liu <=
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Joel Becker, 2010/07/17
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, jeff.liu, 2010/07/17
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, jeff.liu, 2010/07/20
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Joel Becker, 2010/07/15
- bug#6131: [PATCH]: fiemap support for efficient sparse file copy, Paul Eggert, 2010/07/15