Re: Snapshots

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

how about making them mountable filesystems?

  mount -t lfs -osnapshot=3D"january 12, 13:15" /mnt/old

marius.

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
>=20
> 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.
>=20
> 2. Implementation using inode encoding
>     *) For each inode, inode number is derived with a simple function
>        like below
>=20
>         static inline ino_t INUMBER(struct super_block *sb, ino_t ino)
>         {       __u32 snapi =3D CURR_SNAPI(sb);
>=20
>                 snapi =3D snapi << 30;
>                 return ino | snapi;
>         }
>=20
>      *) 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
>=20
> 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.
>=20
> Comments are welcome.
>=20
> 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.
>=20
> --
> Pradeep Padala
> http://ppadala.blogspot.com
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Logfs-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logfs-devel
>=20
>