Re: Snapshots

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

yep.  i think it's totally fine to make this a system daemon.  we need
one anyway for the cleaner.  maybe make the both of them "lfsd."

magic is best done in userland.

marius.

On 8/23/05, Pradeep Padala <pp...@ee...> wrote:
> 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.
>=20
> 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=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 ma=
y
> >>>>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, o=
ne
> >>>>>>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 exist=
ing
> >>>>>>blocks (both inode and data) should be re-directed to new blocks (t=
his
> >>>>>>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 ca=
n
> >>>>>>divide the IFILE into snapshots. For example, the snapshot index (s=
napi)
> >>>>>>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 pointer=
s
> >>>>>>  *) 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. Fo=
r
> >>>>>>      example inode 1 is copied to 0x4001
> >>>>>>   *) switch the root inode to the new inode.
> >>>>>>   *) here comes the tricky part, the directory entries still conta=
in
> >>>>>>      old inodes. so a readdir always ORs the inode number with cur=
rent
> >>>>>>      snapi.
> >>>>>>   *) to access the snapshot, just switch to the old root inode
> >>>>>>
> >>>>>>I have actually switched back and forth, but finally decided to sti=
ck
> >>>>>>with the first implementation as the dentry contents magic is not
> >>>>>>required. It actually doesn't matter other than at the level of cod=
ing
> >>>>>>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 c=
an be
> >>>>>>used to read the contents of inodes etc. and see the snapshot.
> >>>>>>
> >>>>>>--
> >>>>>>Pradeep Padala
> >>>>>>http://ppadala.blogspot.com
> >>
> >>
>=20
> --
> Pradeep Padala
> http://ppadala.blogspot.com
>=20
>