Hi Josef, I have some more questions following up on my previous e-mails. I now do somewhat understand the place where extent entries get cow'ed. But I am unclear about the order of operations.
Is it correct that the data extent written first, then the pointer in the indirect block needs to be updated, so then it is cowed and written to disk and so on recursively up the tree? Or is the entire path from leaf to node that is going to be affected by the write cowed first and then all the cowed extents are written to the disk and then the rest of the metadata pointers, (for example, in checksum tree, extent tree, etc., I am not sure about this)? Also, I need to understand specifically how the data (leaf nodes) of a file is written to disk v/s the metadata including the indirect nodes of the file. In extent_writepage I only know the pages of a file that are to be written. I guess, I can identify metadata pages based on the inode of the page's owner. But is it possible to distinguish the pages available in extent_writepage path as belonging to the leaf node or internal node for a file? If it cannot be identified at this point, where earlier in the path can this be decided? Many thanks, Aastha. On 25 February 2013 20:00, Aastha Mehta <aasth...@gmail.com> wrote: > Ah okay, I now see how it works. Thanks a lot for your response. > > Regards, > Aastha. > > > On 25 February 2013 18:27, Josef Bacik <jba...@fusionio.com> wrote: >> On Mon, Feb 25, 2013 at 08:15:40AM -0700, Aastha Mehta wrote: >>> Thanks again Josef. >>> >>> I understood that cow_file_range is called for a regular file. Just to >>> clarify, in cow_file_range is cow done at the time of reserving >>> extents in the extent btree for the io to be done in this delalloc? I >>> see the following comment above find_free_extent() which is called >>> while trying to reserve extents: >>> >>> /* >>> * walks the btree of allocated extents and find a hole of a given size. >>> * The key ins is changed to record the hole: >>> * ins->objectid == block start >>> * ins->flags = BTRFS_EXTENT_ITEM_KEY >>> * ins->offset == number of blocks >>> * Any available blocks before search_start are skipped. >>> */ >>> >>> This seems to be the only place where a cow might be done, because a >>> key is being inserted into an extent which modifies it. >>> >> >> The key isn't inserted at this time, it's just returned with those values >> for us >> to do as we please. There is no update of the btree until >> insert_reserved_extent/btrfs_mark_extent_written in btrfs_finish_ordered_io. >> Thanks, >> >> Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
