[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lustre-announce
Subject:    Re: [Lustre-discuss] snapfs code
From:       Andreas Dilger <adilger () clusterfs ! com>
Date:       2006-01-06 23:38:16
Message-ID: 20060106233816.GL5587 () schatzie ! adilger ! int
[Download RAW message or body]

On Jan 06, 2006  17:28 -0500, PAulN wrote:
> can you describe how the copy-on-write would work at the ost layer
> or is this still undecided?  from old snapfs code it looks like
> performing a cow op hooks into the underlying filesystem somehow.
> unfortunately i can't find the code for ext3_snap_operations..
> what I'd really like to know is how the cow was intended to work?
> are we talking about file-level or block level cow?  the args to
> create_indirect imply that the entire file is copied.

It was a long time ago that this code was written, but AFAIR the
snapfs code did file-level snapshots, essentially creating a new
inode for each version of the file.  Holes in the file would reference
data in the previous version(s) of the file.  The data was never
copied unless an old snapshot in a partially-modified file was removed
and we still need the old data to make a complete file.

While the theory of "write a few blocks in a modified file" is always
mentioned, in reality every common application except databases
always rewrites the whole file regardless of how much data is changed
(e.g. editors, unix tools, etc).

Just like kernel VM is optimized for fork+exec which normally replaces
the whole process memory space and doesn't actually copy the process
pages, snapfs is optimized for the common case where old file data
is completely replaced.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

_______________________________________________
Lustre-discuss mailing list
Lustre-discuss@lists.clusterfs.com
https://lists.clusterfs.com/mailman/listinfo/lustre-discuss
[prev in list] [next in list] [prev in thread] [next in thread]