Re: Snapshots

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

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.=20
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
>=20
> Yep, thought about it, and is probably what I will have as the first
> version.
>=20
> 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.
>=20
> 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 ?
>=20
> > 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, i=
f
> >>       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 contain
> >>        old inodes. so a readdir always ORs the inode number with curre=
nt
> >>        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 b=
e
> >>used to read the contents of inodes etc. and see the snapshot.
> >>
> >>--
> >>Pradeep Padala
> >>http://ppadala.blogspot.com
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
> >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> >>_______________________________________________
> >>Logfs-devel mailing list
> >>Log...@li...
> >>https://lists.sourceforge.net/lists/listinfo/logfs-devel
>=20
>