Bug 8467 - New shadow-copy vfs module for zfs
Summary: New shadow-copy vfs module for zfs
Status: NEW
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.6.0
Hardware: All Solaris
: P5 normal
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2011-09-17 11:59 UTC by (account disabled)
Modified: 2013-10-01 21:13 UTC (History)
1 user (show)

See Also:

Shadow-copy VFS module for ZFS (40.62 KB, patch)
2011-09-17 11:59 UTC, (account disabled)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description (account disabled) 2011-09-17 11:59:37 UTC
Created attachment 6907 [details]
Shadow-copy VFS module for ZFS

This is a VFS module for exposing ZFS snapshots as shadow-copies. It is
based heavily on the existing shadow_copy2 module, but it does not require
snapshots to conform to any particular naming scheme; instead, it uses
libzfs to directly enumerate the snapshots and their creation times.

This has been tested on Solaris 10, with XP, 2003, 2008R2, and Vista as
clients. It should presumably work on FreeBSD too.
Comment 1 Volker Lendecke 2011-09-17 15:00:21 UTC
Hmmm. Can we do that a bit differently? shadow_copy2 was too hard to maintain, so we completely replaced it in master. I have seen your message that you have problems with shadow_copy3 if the @GMT is in the middle of the path. On GPFS we have definitely tested this, so I would be curious what your test case exactly is. Having another module with the same code structure as shadow_copy2 brings back the burden of having to maintain it. Can we try to get the functionality either into something that is based on shadow_copy3 or sanely extend shadow_copy3?


Comment 2 (account disabled) 2011-09-17 23:50:33 UTC
I was thinking that having a common, base shadow-copy module with different
fs-specific plugins would be the best approach - I very much agree that having
several plugins with lots of identical code is bad. There are now basically
three shadow-copy plugins: the "generic" shadow_copy2, the onefs one, and this
zfs one. And really, they mainly just provide different ways to 1) list the
snapshots (as part of the .get_shadow_copy_data function), and 2) convert paths
with @GMT- tokens to fs paths (the convert_shadow_name() functions) (though
this isn't fully generic as there could be fs' where the snapshots are not
accessible via a simple path traversal, but I'm not sure we have to worry about
that right now).

So in the end the user would configure things something like

  vfs objects = shadow_copy
  shadow:provider = [pattern|onefs|zfs]
  shadow:<provider specific configs>

Anyway, that was my thinking, but I didn't have the time to dig into this
approach and wasn't sure how receptive you would be to all this.
Comment 3 (account disabled) 2011-09-17 23:55:48 UTC
Oh, responding to the shadow_copy3 issue, I did simple testing via smbclient,
such as

  smbclient //host/share -U '...' -c "dir foo/@GMT-2011.09.13-12.34.56/*"

shadow_copy{2,zfs} handle this correctly; shadow_copy3 returns a
NT_STATUS_OBJECT_PATH_NOT_FOUND. Putting @GMT- at the beginning of path
makes this work.
Comment 4 (account disabled) 2011-09-18 00:16:29 UTC
P.S. None of the shadow-copy modules were working properly for us when
accessed from Vista or 2008R2 - you could see the list of snapshots in
the "Previous Versions" tab, but the "Open" and "Copy" buttons were
grayed out and the "Restore" button did nothing whatsoever (it didn't
even send a request to the server). We compared the responses of a 2003
server with those from Samba, and the difference causing this was that
the 2003 server was returning a STATUS_NO_SUCH_FILE to find-first2
requests for \@GMT-yyyy.mm.dd-hh.mm.ss  (i.e. nothing else in the path
besides the @GMT token). Therefore the hack in shadow_copy_zfs_opendir()
in this patch which reproduces that behaviour (I tried all sorts of
variations on the data returned, such as the dates, the attributes, etc,
but nothing seemed to make 2008R2/Vista happy besides returning

Since I couldn't find anybody else complaining about this, I'm not sure
if this a problem specific to zfs, and hence I haven't filed a separate
bug report.