Hello, as the president of the french OSUG [1], I''ll give a talk about ZFS and zones at RMLL [2] (libre software meeting) and I have few questions about Jeff Bonwick''s slides [3], especially for slide 11. I just want to be sure to understand good, here my understanding: (I hope I''m not totally wrong ;p) The slide demonstrate how an existing file is modified. The boxes in blue represents the existing data, and the green ones the new data. So when an application wants modified the existing datas, the existing blocks are copied (only if the modification is more little than the block size I guess ?) to a new one, modifications are made on this new block. Once all changes are made, the superblock (uberblock ?) reference are updated, and since the data (the reference to the new block) are modified, the checksum is recalculate and write in the next block (the upper one). And about the next slide, I''m right, a snapshot is working exactly like that, except that the old data blocks are not freed.. Am I right ? ;p I hope I''m not so far of the truth.. Thank you for your help References: 1/ http://guses.org/home/ 2/ http://rmll.info/ 3/ http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf This message posted from opensolaris.org
Hello Bruno,
Wednesday, June 13, 2007, 3:45:07 PM, you wrote:
BB> Hello,
BB> as the president of the french OSUG [1], I''ll give a talk about
BB> ZFS and zones at RMLL [2] (libre software meeting) and I have few
BB> questions about Jeff Bonwick''s slides [3], especially for slide
11.
BB> I just want to be sure to understand good, here my understanding:
BB> (I hope I''m not totally wrong ;p)
I''m not looking at the slides so I hope I figured it out just from
your description. See below.
BB> The slide demonstrate how an existing file is modified. The boxes
BB> in blue represents the existing data, and the green ones the new
BB> data. So when an application wants modified the existing datas,
BB> the existing blocks are copied (only if the modification is more
BB> little than the block size I guess ?) to a new one, modifications
BB> are made on this new block. Once all changes are made, the
BB> superblock (uberblock ?) reference are updated, and since the data
BB> (the reference to the new block) are modified, the checksum is
BB> recalculate and write in the next block (the upper one).
If full block is overwritten then the old one is not copied - just new
one is written to different location.
If you modify a block partially then the old one is first read (entire
block), checksum is checked, block is modified and written to new
location.
New metadata are written and uberblock is modified at the end (new one
is written in a shifted location). New metadata do not point to old
block which is marked free (or is not freed if there''s a snapshot
referencing to it).
Usually transactions are grouped every 5s so you don''t have to update
metadata and uberblock that often.
BB> And about the next slide, I''m right, a snapshot is working
BB> exactly like that, except that the old data blocks are not freed..
yep
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
> I just want to be sure to understand good, here my understanding: (I > hope I''m not totally wrong ;p) > > The slide demonstrate how an existing file is modified. The boxes in > blue represents the existing data, and the green ones the new data. So > when an application wants modified the existing datas, the existing > blocks are copied (only if the modification is more little than the > block size I guess ?)The blocks aren''t necessarily copied. When a normal filesystem writes data, it sends a block of data to the disk overwriting the old block. It''s immediately seen because the metadata is referencing that physical location. ZFS does the same bit with writing the block to disk, but instead of overwriting the old location, it''s written to a new location, and metadata will be written (again in a new location) that refers to the new data.> to a new one, modifications are made on this new > block. Once all changes are made, the superblock (uberblock ?) > reference are updated, and since the data (the reference to the new > block) are modified, the checksum is recalculate and write in the next > block (the upper one).The checksums and other metadata are written before the uberblock is updated. By having everything thing else ready and consistent, the uberblock change makes it an atomic activation.> And about the next slide, I''m right, a snapshot is working exactly > like that, except that the old data blocks are not freed..Correct. The blocks are freed when they''re no longer in use, and a snapshot counts as use. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >