BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mapping inode numbers to file names
- Subject: Mapping inode numbers to file names
- From: blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org (Edward Ned Harvey)
- Date: Tue, 27 Apr 2010 22:42:41 -0400
- In-reply-to: 4BD6EE62.1040709-mNDKBlG2WHs@public.gmane.org
- References: 4BD6EE62.1040709@blu.org, <001301cae60c$b043a660$10caf320$@com> 4BD6EE62.1040709@blu.org
> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On > Behalf Of John Chambers > > In Edward's scenario, you actually know something more that could be > used to > radically trim the search. You know the path to the file. Even if > these are > different "in real life", you can still use them. What you do is trace Oh - Apparently I didn't make that clear - The directories haven't been simply renamed. The directories *may* have been renamed, but that's not the point. As you said, I could solve that problem easily. It's the file that's renamed, *and* located in a different directory. Such as... mkdir -p a/b/c/d/e touch a/b/c/d/e/foo.txt mkdir -p f/g/h/i/j (create snapshot) mv a/b/c/d/e/foo.txt f/g/h/i/j/BAR Now, if somebody wants to find a previous version of f/g/h/i/j/BAR, the correct location would be /a/.zfs/snapshot/snapname/b/c/d/e/foo.txt And the problem at hand is ... What's the fastest way to identify the correct snapshot path.
- References:
- Mapping inode numbers to file names
- From: solaris2-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org (Edward Ned Harvey)
- Mapping inode numbers to file names
- Prev by Date: Mapping inode numbers to file names
- Next by Date: Mapping inode numbers to file names
- Previous by thread: Mapping inode numbers to file names
- Next by thread: Mapping inode numbers to file names
- Index(es):