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
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
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: 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 afshin.sa...@oracle.com 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
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
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
