[Box Backup-dev] Re: Learning from ZFS (fwd)

[Stuart Hickinbottom]

That's very interesting. I'd read about ZFS previously and seen it had 
many of the features that we rely on BB to provide at the moment.

What I'd be most interested in is some roadmap process that would get us 
here, with some (I suspect) FAQs about that process. In particular:

1. Will existing stores be portable to the new store format? I'm pretty 
certain that it's 'no', but that would be a significant issue for 
existing users who have a large amount of legacy remote data and slow 
data links (eg the internet). Perhaps it would at least be possible to 
convert an existing store in a one-way process?
2. What clients and server OS's would be supported? I see there's 
work-in-progress for ZFS over FUSE for Linux, but would this be 
supported for both client and server, and what about other OS's?
3. The current network protocol, whilst it has had its share of problems 
with things like timeouts and large files, does work quite well over 
unreliable links such as the internet. Would a reliance on ZFS mounted 
remotely over such links cause problems with reliability and recovery 
when those links drop connections? Perhaps there are no problems, but 
I've tried tunnelling network filesystems before and have had such 
issues (principally, /cringe/ when I was trying to do that with Samba).
4. Is this independent on any work to release 0.11 in the near future?

What is the driver for such a significant departure, I wonder? Whilst, 
of course, the development is going to go in whatever direction the 
developers would like, why is the current architecture considered in 
need of replacement?

There has now been a lot of testing and usage of BB over a number of 
years and that would be effectively cancelled for a new architecture 
based on ZFS (and, indeed, ports of ZFS will come with their own 
difficulties since they're quite new and not widely used). Don't get me 
wrong - I'm not against such a departure at all and it would give me a 
chance to play with some new toys, but I'm interested in whether there's 
a reason other than that it will be a nice change for us all.

Stuart

Chris Wilson wrote:
> Hi all,
>
> Ben and I have been discussing how we could possibly use Sun's Solaris 
> ZFS to provide most of the functionality of Box Backup. We could get 
> the rest with a couple of layers above and below ZFS, which would make 
> Box much simpler and give us cool features like versioning and snapshots.
>
> We think we should move this to the -dev list so that we can all 
> discuss it.
>
> We're discussing two possible approaches, not necessarily incompatible 
> or either-or, just talking points:
>
> Option 1. Any filesystem on client, sync to encrypted filesystem (like 
> encfs) on top of zfs on top of iscsi block device (which is mounted 
> from the server, over the net).
>
> Advantages: supports any filesystem on client. Very simple server 
> (effectively a network block device) which holds ZFS images which are 
> managed entirely by the client. The server could in principle mount 
> these images locally, but would see only encrypted filenames and data.
>
> Disadvantages: more complex and less efficient than 2.
>
> Option 2. Client runs encfs on top of local zfs, synchronises this to 
> remote ZFS periodically, as Ben describes below.
>
> Advantages: more efficient (we think), simpler Box code (encrypted 
> filesystem only)
>
> Disadvantages: requires kernel support, especially to run ZFS in the 
> kernel in most cases. requires client to run zfs filesystems.
>
> The message below is part of our discussion. If anyone is lost or 
> needs more introduction to the issue, please ask. I'll reply to Ben's 
> email below, shortly.
>
> Cheers, Chris.