On Fri, Feb 4, 2011 at 2:20 AM, Joel Becker <jlbec@xxxxxxxxxxxx> wrote: > On Fri, Feb 04, 2011 at 12:33:39AM +0200, Amir Goldstein wrote: >> I have been working on porting Next3 snapshots to Ext4 >> with a group of 4 CS students. >> >> This is where it all happens: >> https://github.com/amir73il/ext4-snapshots >> >> Ext4 snapshots prototype is already working! >> Would you like to see a demo? >> >> I would like to present the progress of our work >> and discuss the remaining issues and how they should be best addressed. >> >> Additionally, I would like to discuss the need for a unified snapshots API that >> would serve both Ext4 and Btrfs. >> This could be useful for someone that wants to implement a generic >> snapshots management system. > > ocfs2 definitely wants to be a part of that discussion, as we > already do snapshots and thin clones. ocfs2 snapshots are actually just > thin clones marked readonly. They can be placed anywhere in the > filesystem and are first-class inodes. They do not live in a hidden > space like Next3 snapshots seem to. > I've already got a design for a front-end snapshot program that > implements a policy on top this generic behavior. This design would > cover both first-class and hidden style snapshots, because it assume > snapshots are in a distinct namespace. I haven't gotten around to > implementing it yet, but btrfs and other snapshottable filesystems were > part of the design goal. > > Joel > Hi Joel, Any chance of getting a copy of that design of yours, to get a head start for LSF? Here are some other generic snapshot related topics we may want to discuss: 1. Collaborating the use of inode flags COW_FL, NOCOW_FL, suggested by Chris. 2. How to deal with mmap write to COW file, when you get ENOSPC. 3. Adding buffer_remap() flag for buffered I/O code, meaning, there is an existing mapping to initialize a page on partial write, but still need to call get_block() to get a (possibly) new mapping. I'll be staying for Collaboration summit, so I've got plenty of time if you like to exchange some ideas. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
