From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-f180.google.com ([209.85.210.180]:40994 "EHLO mail-ia0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754640Ab3BWJdZ (ORCPT ); Sat, 23 Feb 2013 04:33:25 -0500 Received: by mail-ia0-f180.google.com with SMTP id f27so1215939iae.25 for ; Sat, 23 Feb 2013 01:33:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20130220175410.GB2062@localhost.localdomain> From: Aastha Mehta Date: Sat, 23 Feb 2013 10:33:03 +0100 Message-ID: Subject: Re: basic questions regarding COW in Btrfs To: Josef Bacik Cc: linux-btrfs Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-btrfs-owner@vger.kernel.org List-ID: A gentle reminder on this one. Thanks, Aastha. On 21 February 2013 18:32, Aastha Mehta wrote: > Thanks a lot for the prompt response. I had seen that, but I am still > not sure of where it really > happens within fill_delalloc. Could you help me a little further in that path? > > Secondly, now I am confused between the btree_writepages and > btrfs_writepages/btrfs_writepage > methods. I thought btrfs_writepages was for writing the pages holding > inodes and btree_writepages > for writing the other indirect and leaf extents of the btree. Then, it > seems that the write operations > lead to update of the file system data structures in a top-down > manner, i.e. first changing the inode > and then the data extents. Is that correct? > > Thirdly, it seems that the old extents maybe dropped before the new > extents are flushed to the disk. > What would happen if the write fails before the disk commit? What am I > missing here? > > Thanks, > Aastha. > > On 20 February 2013 18:54, Josef Bacik wrote: >> On Wed, Feb 20, 2013 at 10:28:10AM -0700, Aastha Mehta wrote: >>> Hello, >>> >>> I am trying to understand the COW mechanism in Btrfs. Is it correct to >>> say that unless nodatacow option is specified, Btrfs always performs >>> COW for all the data+metadata extents used in the system? >>> >> >> So we always cow the metadata, but yes nodatacow means we don't cow the actual >> data in the data extents. >> >>> I saw that COWing is implemented in btrfs_cow_block() function, which >>> is called at the time of searching a slot for a particular item, while >>> inserting into a new slot, committing transactions, while creating >>> pending snapshots and few other places. >>> >>> However, while tracing through the complete write path, I could not >>> quite figure out when extents actually get COWed. Could you please >>> point me to the place where COWing takes place? Is there any time >>> when, for performance or any other reasons, the extents are not COWed >>> but overwritten in place (apart from the explicit nodatacow flag being >>> set during mount)? >> >> You'll want to look at the tree operation ->fill_delalloc(). Thats where we do >> cow_file_range(). We allocate new space and write. When we finish the ordered >> io we do btrfs_drop_extents() on the range we just wrote which will free up any >> existing extents that exist, and then insert our new file extent. Thanks, >> >> Josef -- Aastha Mehta MPI-SWS, Germany E-mail: aasthakm@mpi-sws.org