Re: Snapshots

[Marius E. <ma...@mo...>]

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=20

  /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.
>=20
> 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=3D"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 th=
e
> >>>>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 existin=
g
> >>>>blocks (both inode and data) should be re-directed to new blocks (thi=
s
> >>>>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 (sna=
pi)
> >>>>can be used to encode within the inode number (say first two bits). S=
o,
> >>>>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 =3D CURR_SNAPI(sb);
> >>>>
> >>>>               snapi =3D 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 contai=
n
> >>>>       old inodes. so a readdir always ORs the inode number with curr=
ent
> >>>>       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 codin=
g
> >>>>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
>=20
>