On Sat, Oct 20, 2012 at 1:24 PM, Tim Cook <t...@cook.ms> wrote: > > > On Sat, Oct 20, 2012 at 2:54 AM, Arne Jansen <sensi...@gmx.net> wrote: > >> On 10/20/2012 01:10 AM, Tim Cook wrote: >> > >> > >> > On Fri, Oct 19, 2012 at 3:46 PM, Arne Jansen <sensi...@gmx.net >> > <mailto:sensi...@gmx.net>> wrote: >> > >> > On 10/19/2012 09:58 PM, Matthew Ahrens wrote: >> > > On Wed, Oct 17, 2012 at 5:29 AM, Arne Jansen <sensi...@gmx.net >> > <mailto:sensi...@gmx.net> >> > > <mailto:sensi...@gmx.net <mailto: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. >> > > >> > > >> > > >> > > Please don't bother changing libzfs (and proliferating the >> copypasta >> > > there) -- do it like lzc_send(). >> > > >> > >> > ok. It would be easier though if zfs_send would also already use the >> > new style. Is it in the pipeline already? >> > >> > > Likewise, zfs_ioc_fits_send should use the new-style API. See the >> > > comment at the beginning of zfs_ioctl.c. >> > > >> > > I'm not a fan of the name "FITS" but I suppose somebody else >> already >> > > named the format. If we are going to follow someone else's format >> > > though, it at least needs to be well-documented. Where can we >> > find the >> > > documentation? >> > > >> > > FYI, #1 google hit for "FITS": http://en.wikipedia.org/wiki/FITS >> > > #3 hit: http://code.google.com/p/fits/ >> > > >> > > Both have to do with file formats. The entire first page of >> google >> > > results for "FITS format" and "FITS file format" are related to >> these >> > > two formats. "FITS btrfs" didn't return anything specific to the >> file >> > > format, either. >> > >> > It's not too late to change it, but I have a hard time coming up >> with >> > some better name. Also, the format is still very new and I'm sure >> it'll >> > need some adjustments. >> > >> > -arne >> > >> > > >> > > --matt >> > >> > >> > >> > I'm sure we can come up with something. Are you planning on this being >> > solely for ZFS, or a larger architecture for replication both directions >> > in the future? >> >> We have senders for zfs and btrfs. The planned receiver will be mostly >> filesystem agnostic and can work on a much broader range. It basically >> only needs to know how to create snapshots and where to store a few >> meta informations. >> It would be great if more filesystems would join on the sending side, >> but I have no involvement there. >> >> I see no basic problem in choosing a name that's already in use. >> Especially with file extensions most will be already taken. How about >> something with 'portable' and 'backup', like pib or pibs? 'i' for >> incremental. >> >> -Arne >> >> > Re-using names generally isn't a big deal, but in this case the existing > name is a technology that's extremely similar to what you're doing - which > WILL cause a ton of confusion in the userbase, and make troubleshooting far > more difficult when searching google/etc looking for links to documents > that are applicable. > > Maybe something like far - filesystem agnostic replication? >
All else being equal, I like this name (FAR). It ends in "AR" like several other archive formats (TAR, WAR, JAR). Plus not a lot of false positives when googling around for it. However, if compatibility with the existing format is an explicit goal, we should use the same name, and the btrfs authors may be averse to changing the name. --matt
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
