Arne, I took a look at far.c in
http://cr.illumos.org/~webrev/sensille/far-send/. Here are some
high-level comments:
Why did you choose to do this all in the kernel? As opposed to the
way "zfs diff" works, where the kernel generates the list of changed
items and then userland sorts out what exactly changed in each block
and how that relates to the "from" snapshot. Do you need information
that isn't available through the regular POSIX ioctls?
Why do you need far_find_from_bp(), rather than reading the from
snapshot through the "front door", e.g. dmu_buf_hold()?
The big comment at the beginning is very helpful. However there are
several typos / missing words. Also could you explain what you mean
by "put back"?
A comment says that far_sa_setup was copied from zfs_znode.c. If this
is the case, you need to also copy the copyright notices in
zfs_znode.c (or just the ones that apply, if you want to bother
digging through the history).
far_find_from_bp(): why do you need to clear out the lower level
blklevel_t's every time through the loop? Would it suffice to clear
them all out at the beginning?
In Illumos, we declare structs as "typedef struct x { ... } x_t;".
(note there is no underscore before the type name).
The ASSERT3U() family of macros are pretty useful. Consider using
them instead of plain ASSERT() where possible.
The blklevel_t structure is pretty complicated; is there a comment
somewhere saying what it represents? E.g. that bl_bp is an array of
length bl_nslots? Additionally, you could give the variables
descriptive names ("bl_bps" and "bl_nbps" would be maximally terse but
still give some clue as to what they are). Also it seems like bp_bp
== bl_buf->b_data?
--matt
On Wed, Oct 17, 2012 at 5:29 AM, Arne Jansen <sensi...@gmx.net> wrote:
> We have finished a beta version of the feature. A webrev for it
> can be found here:
>
> http://cr.illumos.org/~webrev/sensille/fits-send/
>
> It adds a command 'zfs fits-send'. The resulting streams can
> currently only be received on btrfs, but more receivers will
> follow.
> It would be great if anyone interested could give it some testing
> and/or review. If there are no objections, I'll send a formal
> webrev soon.
>
> Thanks,
> Arne
>
>
> On 10.10.2012 21:38, Arne Jansen wrote:
>> Hi,
>>
>> We're currently working on a feature to send zfs streams in a portable
>> format that can be received on any filesystem.
>> It is a kernel patch that generates the stream directly from kernel,
>> analogous to what zfs send does.
>> The stream format is based on the btrfs send format. The basic idea
>> is to just send commands like mkdir, unlink, create, write, etc.
>> For incremental sends it's the same idea.
>> The receiving side is user mode only, so it's very easy to port it to
>> any system. If the receiving side has the capability to create
>> snapshots, those from the sending side will get recreated. If not,
>> you still have the benefit of fast incremental transfers.
>>
>> My question is if there's any interest in this feature and if it had
>> chances of getting accepted. Also, would it be acceptable to start with
>> a working version and add performance optimizations later on?
>>
>> -Arne
>
>
> -------------------------------------------
> illumos-zfs
> Archives: https://www.listbox.com/member/archive/182191/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182191/21635000-ebd1d460
> Modify Your Subscription:
> https://www.listbox.com/member/?member_id=21635000&id_secret=21635000-73dc201a
> Powered by Listbox: http://www.listbox.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
