On Thu, Sep 06, 2007 at 01:43:21PM -0700, Matthew Ahrens wrote:
> Joerg Schilling wrote:
> > Matthew Ahrens <[EMAIL PROTECTED]> wrote:
> > 
> >> Joerg Schilling wrote:
> >>> The best documented one is the inverted meta data tree that allows wofs 
> >>> to write
> >>> only one new generation node for one modified file while ZFS needs to 
> >>> also write new
> >>> nodes for all directories above the file including the root directory in 
> >>> the fs.
> >> I believe you are thinking of indirect blocks, which are unrelated to the 
> >> directory tree.  In ZFS and most other filesystems, ancestor directories 
> >> need 
> >> not be modified when a file in a directory is modified.
> > 
> > Isn't this against what I've read?
> > 
> > If you write inode data to a different location than before, you need a way 
> > to 
> > tell the ancestor directory where the new data is located.
> 
> No; directories point to the files (and directories) that they contain by 
> object (inode) number, not by block pointer (physical disk location).  When 
> new contents are written to a file, its object (inode) number does not change.

When you modify a file ZFS writes a new block and new indirect blocks if
needed and a new dnode (inode) and it updates the special file that maps
dnode numbers to block pointers, which means writing a new block,
possibly new indirect blocks, and a new dnode for that special file.
All in one transaction.  Parent directories up to / are not affected
(dnodes don't even have pointers to them, which wouldn't be easy to do
anyways given POSIX hard-link semantics).  That's what I understood.

Which, BTW, is *exactly* how the 4.4BSD Log Structure Filesystem works.
That is, LFS has a special file mapping inode numbers to block pointers
and updates to any file involve the same approach of writing new blocks
for the affected file and that special file (other details, of course,
differ, such as the structure of ZFS block pointers vs. LFS').
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to