Re: [cifs-discuss] "previous versions" internals
> From: Alan Wright [mailto:alan.wri...@oracle.com] > > ... Thank you. FWIW, I'm aware of the difference in behavior if finding snapshots based on inode versus assuming unchanged pathname/filename. The path/filename is much more easily implemented, due to the general lack of ability to reverse lookup inode --> pathname, so I'll expect to do the filename version first, and add the option of searching by inode later. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
Edward Ned Harvey wrote: From: Afshin Salek [mailto:afshin.sa...@oracle.com] Here are some pointers: usr/src/uts/common/fs/smbsrv/smb_vss.c (smb kernel module) usr/src/cmd/smbsrv/smbd/smbd_vss.c (smbd daemon) Is it really difficult just to say "It's based on path and filename" or "It's based on inodes" or "It's not based on either of those, it's more complex, I'd recommend reading the code if you'd like to know more." An unqualified answer might be misleading and trying to provide a detailed answer without some common basis for the discussion will probably be confusing. For example, Previous Versions involves a reserved token provided by the client, which determines where the previous versions must be located. While this has relevance only over SMB, it tends to drive towards a model based on file system layout rather than znodes/inodes ... but awareness of the mount hierarchy is required because you may need to locate the correct .zfs within a hierarchy of file systems (some of which may be zfs and some may be something else), and how you determine that will probably depend on the programming language or infrastructure you have chosen. I mean, I feel like you're insulting me. Not at all, this is why it's important to provide context and perspective. You didn't mention your areas of expertise and this is the typical answer one would get to such a question within our organization. I think it would be worth having a look at the Microsoft specs, which are available here: http://msdn.microsoft.com/en-us/library/cc964399%28PROT.10%29.aspx Look for "[MS-SMB]: Server Message Block (SMB) Protocol Specification" and search the PDF for "Previous Version". There are lots references to that phrase in the document. The name and location of the file is critical to Windows Previous Versions. If you move or rename an object, it may affect the results. Network captures, taken while a Windows client is accessing Previous Versions, will illustrate this very clearly. A similar approach would work for your zhist command but it depends on how you want to spec it. It might be possible to use file nodes, although you'd have to take the mount point (vfs id) into account and it might provide different, and possibly undesirable, results. Using your /tank/home/eharvey/working/foo/bar example, let's assume that tank, home and eharvey are different datasets. Would the following work: zhist ls /tank/home/eharvey/working/foo/bar Note that you can't get to bar in this example via /tank/.zfs/snapshot/... Suppose I have a symlink (fred is another dataset): /tank/home/fred/bar -> ../eharvey/working/foo/bar Since the target is in another dataset, should 'zhist ls /tank/home/fred/bar' show me the previous versions of /tank/home/eharvey/working/foo/bar? Or worse, suppose bar is a hard link? Would this be possible if the implementation was based on inodes/znodes? How you model this will depend on the scope and requirements you place on zhist. Alan ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
> From: Afshin Salek [mailto:afshin.sa...@oracle.com] > > Here are some pointers: > > usr/src/uts/common/fs/smbsrv/smb_vss.c (smb kernel module) > usr/src/cmd/smbsrv/smbd/smbd_vss.c (smbd daemon) Is it really difficult just to say "It's based on path and filename" or "It's based on inodes" or "It's not based on either of those, it's more complex, I'd recommend reading the code if you'd like to know more." I mean, I feel like you're insulting me. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
Here are some pointers: usr/src/uts/common/fs/smbsrv/smb_vss.c (smb kernel module) usr/src/cmd/smbsrv/smbd/smbd_vss.c (smbd daemon) Afshin On 05/ 5/10 01:17 PM, Edward Ned Harvey wrote: From: Afshin Salek [mailto:afshin.sa...@oracle.com] Solaris is open source, you can always take a look at the code to see what it does ;-) That's not helpful. ;-) I've been trying to do that, but I'm overwhelmed by the massive code, and total unfamiliarity with all the thousands of source files. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
On Wed, May 5, 2010 at 8:57 PM, Afshin Salek wrote: > Solaris is open source, you can always take a look at the > code to see what it does ;-) Easy to say, but I suspect that trawling through what, 20 million lines of unfamiliar code, or is it more now, is likely to prove frustrating to most. Having a basic map to the source, to the point of being given a hint by someone reasonably familiar with it as to which bit of the source to start looking at rather than having to hunt through the whole lot, would help someone like Ned immensely, and I think that's what he was after. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
> From: Afshin Salek [mailto:afshin.sa...@oracle.com] > > Solaris is open source, you can always take a look at the > code to see what it does ;-) That's not helpful. ;-) I've been trying to do that, but I'm overwhelmed by the massive code, and total unfamiliarity with all the thousands of source files. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
Solaris is open source, you can always take a look at the code to see what it does ;-) Afshin On 05/ 5/10 10:17 AM, Edward Ned Harvey wrote: From: Alan Wright [mailto:alan.wri...@oracle.com] Sent: Tuesday, May 04, 2010 6:28 PM Is this a curiosity question or are you trying to implement support for Previous Versions? Have you looked at the spec and/or what Windows clients do when you view Previous Versions? I don't know where to find the spec, but I am specifically interested in how zfs snapshots are translated to previous versions. If we're talking about a general spec, as implemented by MS Windows servers or anything other than ZFS, I'm not interested in that. Only interested in ZFS. The reason I'm interested is: I've begun work on something called "zhist" This is a cross-platform python script, which is meant to simplify access to snapshots. The simple and obvious thing to do is to base it on filenames. If a user does something like "zhist ls somefile" then zhist climbs up to the proper parent directory of somefile, enters the .zfs/snapshot directory, and produces a list of all the matching instances of somefile. For example: cd /tank/home/eharvey/working/foo zhist ls bar Results in: /tank/.zfs/snapshot/snap1/home/eharvey/working/foo/bar /tank/.zfs/snapshot/snap2/home/eharvey/working/foo/bar /tank/.zfs/snapshot/snap.../home/eharvey/working/foo/bar Then, somebody in zfs-discuss asked me, "what if the thing has been renamed, or moved to a different directory?" ... Well, this technique of finding object previous versions based on filename and path cannot identify renames and moves. So then there was this whole discussion about reverse lookup inode --> names. This discussion didn't really progress much. So then somebody suggested, "Hey, doesn't CIFS previous versions already do this? Why don't you ask them how they do it?" So here I am. I don't want to presume I've thought up every possible algorithm to identify previous versions of an object. So instead of asking "Hey, do you guys search by matching filename and path in the snapshots, or use reverse inode-->pathname lookup," I felt it was more appropriate to ask, "What technique is being used, to map snapshots to previous versions." So ... Can you answer the question, or tell me where to look so I can read about it? Thanks... ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
> From: Alan Wright [mailto:alan.wri...@oracle.com] > Sent: Tuesday, May 04, 2010 6:28 PM > > Is this a curiosity question or are you trying to implement > support for Previous Versions? > > Have you looked at the spec and/or what Windows clients do > when you view Previous Versions? I don't know where to find the spec, but I am specifically interested in how zfs snapshots are translated to previous versions. If we're talking about a general spec, as implemented by MS Windows servers or anything other than ZFS, I'm not interested in that. Only interested in ZFS. The reason I'm interested is: I've begun work on something called "zhist" This is a cross-platform python script, which is meant to simplify access to snapshots. The simple and obvious thing to do is to base it on filenames. If a user does something like "zhist ls somefile" then zhist climbs up to the proper parent directory of somefile, enters the .zfs/snapshot directory, and produces a list of all the matching instances of somefile. For example: cd /tank/home/eharvey/working/foo zhist ls bar Results in: /tank/.zfs/snapshot/snap1/home/eharvey/working/foo/bar /tank/.zfs/snapshot/snap2/home/eharvey/working/foo/bar /tank/.zfs/snapshot/snap.../home/eharvey/working/foo/bar Then, somebody in zfs-discuss asked me, "what if the thing has been renamed, or moved to a different directory?" ... Well, this technique of finding object previous versions based on filename and path cannot identify renames and moves. So then there was this whole discussion about reverse lookup inode --> names. This discussion didn't really progress much. So then somebody suggested, "Hey, doesn't CIFS previous versions already do this? Why don't you ask them how they do it?" So here I am. I don't want to presume I've thought up every possible algorithm to identify previous versions of an object. So instead of asking "Hey, do you guys search by matching filename and path in the snapshots, or use reverse inode-->pathname lookup," I felt it was more appropriate to ask, "What technique is being used, to map snapshots to previous versions." So ... Can you answer the question, or tell me where to look so I can read about it? Thanks... ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] "previous versions" internals
Is this a curiosity question or are you trying to implement support for Previous Versions? Have you looked at the spec and/or what Windows clients do when you view Previous Versions? Alan On 05/ 4/10 06:02 AM, Edward Ned Harvey wrote: This may be a simple question, or it may be hugely complex. If it is hugely complex, please don't hold back, shorten, or simplify your answer for my benefit. ;-) I understand, when you right-click and go to "Previous Versions" it's generating the list of previous versions based on snapshots. What I am wondering about is ... There are many different possible techniques to translate from snapshots to previous versions. I am wondering which technique(s) is/are being used to generate that translation. For example, one simple technique is to blindly assume the name and location of an object has not changed. If a user looks for previous versions of "/tank/foo/bar.txt" then the system would identify "/tank/.zfs/snapshot/snapname/foo/bar.txt" because it has precisely the same name and path as the live filesystem. There are some situations where that would be suboptimal. If path names have been renamed, or moved, then the system wouldn't be able to find previous versions of that object. Another technique would be to identify the inode in the present filesystem, and then reverse-resolve that inode to pathname in all the snapshots, thus locating all the previous versions of that object, even if it's been renamed or relocated. My understanding is that this reverse inode-to-pathname technique is not currently possible for files, because files have no reference to their parent directory(ies), but every directory has a '..' entry which references its parent. So this reverse-lookup from inode to pathname is at least theoretically possible for directories in the present version of ZFS. Or nearly any filesystem, including non-ZFS systems. So, my question is, precisely how the "previous versions" list gets generated from snapshots. Thank you... ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
