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.
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? Thanks, Volker
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.
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.
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 no-such-file). 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.