on Sat Feb 21 2009, Miles Nordin <carton-AT-Ivy.NET> wrote: >>>>>> "da" == David Abrahams <d...@boostpro.com> writes: >>>>>> "ic" == Ian Collins <i...@ianshome.com> writes: > > da> disadvantage of the recommended approaches shows up when you > da> start taking advantage of ZFS to clone filesystems without > da> replicating storage. Using "zfs send" will avoid representing > da> the data twice > > Two or three people wanted S3 support,
Amazon S3 support directly in ZFS? I'd like that, but I'm not sure what it looks like. There are already tools that will send / receive ZFS to Amazon S3. Is there something you can only do well if you own the filesystem code? > but IMVHO maybe S3 is too expensive and is better applied to getting > another decade out of aging, reliable operating systems, and ZFS > architecture should work towards replacing S3 not toward pandering to > it. Replacing S3? > Many new ZFS users are convinced to try ZFS because they want to back > up non-ZFS filesystems onto zpool's because it's better than tape, so > that's not a crazy idea. Not crazy, unless you need to get the backups off-site. > It's plausible to want one backup server with a big slow pool, > deliberately running a Solaris release newer than anything else in > your lab. Then have tens of Solaris's of various tooth-length 'zfs > send'ing from many pools toward one pool on the backup server. The > obvious way to move a filesystem rather than a pool from older Solaris > to newer, is 'zfs send | zfs recv'. > > The obvious problem: this doesn't always work. Because they might break the send/recv format across versions. > The less obvious problem: how do you restore? It's one thing to say, > ``I want it to always work to zfs send from an older system to a > newer,'' which we are NOT saying yet. To make restore work, we need > to promise more: ``the format of the 'zfs send' stream depends only on > the version number of the ZFS filesystem being sent, not on the zpool > version and not on the build of the sending OS.'' That's a more > aggressive compatibility guarantee than anyone's suggested so far, > never mind what we have. Sure. But maybe send/recv aren't the right tools for this problem. I'm just looking for *a way* to avoid storing lots of backup copies of cloned filesystems; I'm not asking that it be called send/recv. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
