Re: Snapshots

[Pradeep P. <pp...@ee...>]

Ok, I see it. You mean by using mount --bind. Yep, this is actually 
quite cool. We don't have to do any readdir/read_inode magic to support 
.snapshot. Only problem I see is that mount cannot be invoked by a 
normal user, and a daemon with root privileges should be given the 
responsibility of keeping track of these snapshot directories.

Marius Eriksen wrote:
> i believe in linux you can do things such as:
> 
>    alias /usr/foo/bar to /home/marius/foo
> 
> and everything under /usr/foo/bar appears under /home/marius/foo.
> 
> basically what the nullfs stackable filesystem does, but it works with
> dentrycache magic.
> 
> so, for example, let's say you were to support ~/.snapshots/hourly.2,
> then you might have
> 
>   /mnt/hourly.2
> 
> and alias 
> 
>   /mnt/hourly.2/home/marius/ to /home/marius/.snapshots/hourly.2
> 
> marius.
> 
> On 8/23/05, Pradeep Padala <pp...@ee...> wrote:
> 
>>Umm, interesting. What exactly do you mean by namespace aliasing? An
>>example would make things clearer for me.
>>
>>Marius Eriksen wrote:
>>
>>>i think that this should be purely a userland administrative thing.
>>>
>>>i.e., all that is needed is the ability to mount a particular
>>>snapshot.  (and of course, to make said snapshots).
>>>
>>>then, you can have a daemon that manages ~/.snapshot directories.
>>>this should be especially doable with the namespace aliasing that
>>>linux can do.
>>>
>>>marius.
>>>
>>>On 8/23/05, Pradeep Padala <pp...@ee...> wrote:
>>>
>>>
>>>>Marius Eriksen wrote:
>>>>
>>>>
>>>>>how about making them mountable filesystems?
>>>>>
>>>>> mount -t lfs -osnapshot="january 12, 13:15" /mnt/old
>>>>
>>>>Yep, thought about it, and is probably what I will have as the first
>>>>version.
>>>>
>>>>In NetAPP's WAFL, for each dir .snapshot contains something like
>>>>hourly.0/ hourly.1/ ... weekly.0/ ...
>>>>Under these directories you can find snapshots for corresponding
>>>>directories.
>>>>
>>>>This is certainly doable, but requires more careful thought, as we may
>>>>have to alternate between IFILEs as the user cds back and forth, not
>>>>trivial. Thoughts ?
>>>>
>>>>
>>>>
>>>>>On 8/23/05, Pradeep Padala <pp...@ee...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>> The final piece in the puzzle is in. I have checked in the basic
>>>>>>framework for doing snapshots. I haven't yet decided on the user
>>>>>>intreface (may be .snapshots like NetAPP does), but you can access the
>>>>>>snapshots using lfsread program.
>>>>>> I want to explain a little bit about the design.
>>>>>> I have toyed around with two different ways of implementing
>>>>>>snapshots, theoritically actually same. To support any snapshots, one
>>>>>>has to make a copy of the inode map (in LFS case IFILE) and fs
>>>>>>modifications are done to the new IFILE only. Also, writes to existing
>>>>>>blocks (both inode and data) should be re-directed to new blocks (this
>>>>>>is almost trivial in LFS).
>>>>>>  Now, how do we make a copy of inode map? We can simply make a new
>>>>>>IFILE file, copy the contents and start using the new file or We can
>>>>>>divide the IFILE into snapshots. For example, the snapshot index (snapi)
>>>>>>can be used to encode within the inode number (say first two bits). So,
>>>>>>the operations are roughly as follows
>>>>>>
>>>>>>1. Implementation using IFILE copy
>>>>>>  *) the on-disk/in-memory inode structure has snapi.
>>>>>>  *) user calls LFS_SNAP_CREATE ioctl
>>>>>>  *) make a copy of IFILE, ++snapi, set the new IFILE inode pointers
>>>>>>  *) when a file is written its snapi is compared to current snapi, if
>>>>>>     they differ new block is created.
>>>>>>  *) to access the snapshot just switch the IFILE. Temporarily
>>>>>>     switching IFILE back and forth is not that trivial though.
>>>>>>
>>>>>>2. Implementation using inode encoding
>>>>>>  *) For each inode, inode number is derived with a simple function
>>>>>>     like below
>>>>>>
>>>>>>      static inline ino_t INUMBER(struct super_block *sb, ino_t ino)
>>>>>>      {       __u32 snapi = CURR_SNAPI(sb);
>>>>>>
>>>>>>              snapi = snapi << 30;
>>>>>>              return ino | snapi;
>>>>>>      }
>>>>>>
>>>>>>   *) user calls LFS_SNAP_CREATE ioctl
>>>>>>   *) make a copy of existing inodes to correponding new inodes. For
>>>>>>      example inode 1 is copied to 0x4001
>>>>>>   *) switch the root inode to the new inode.
>>>>>>   *) here comes the tricky part, the directory entries still contain
>>>>>>      old inodes. so a readdir always ORs the inode number with current
>>>>>>      snapi.
>>>>>>   *) to access the snapshot, just switch to the old root inode
>>>>>>
>>>>>>I have actually switched back and forth, but finally decided to stick
>>>>>>with the first implementation as the dentry contents magic is not
>>>>>>required. It actually doesn't matter other than at the level of coding
>>>>>>complexity/clarity. I also kept a local copy of the second
>>>>>>implementation in case I need it.
>>>>>>
>>>>>>Comments are welcome.
>>>>>>
>>>>>>lfsprogs/lfssnap.c can be used to make snapshot. lfsprogs/lfsread can be
>>>>>>used to read the contents of inodes etc. and see the snapshot.
>>>>>>
>>>>>>--
>>>>>>Pradeep Padala
>>>>>>http://ppadala.blogspot.com
>>
>>

-- 
Pradeep Padala
http://ppadala.blogspot.com