Re: Snapshots

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

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
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Logfs-devel mailing list
>>Log...@li...
>>https://lists.sourceforge.net/lists/listinfo/logfs-devel