I must admit, it is quite convoluted :-)
Please tell me if I understand this. A file system tree (containing
the inodes, the extents of all the inodes, etc.) is itself laid out in
the leaf extents of another big tree, which is the root tree. This is
why you say that inode and other such metadata
On Mon, Mar 4, 2013 at 7:57 PM, Aastha Mehta aasth...@gmail.com wrote:
I must admit, it is quite convoluted :-)
Please tell me if I understand this. A file system tree (containing
the inodes, the extents of all the inodes, etc.) is itself laid out in
the leaf extents of another big tree,
Okay, that makes lot more sense to me now.
Thank you very much.
Regards,
Aastha.
On 5 March 2013 02:51, Josef Bacik jo...@toxicpanda.com wrote:
On Mon, Mar 4, 2013 at 7:57 PM, Aastha Mehta aasth...@gmail.com wrote:
I must admit, it is quite convoluted :-)
Please tell me if I understand
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
On Sat, Mar 2, 2013 at 4:07 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Josef,
I hope it's ok to piggy back on this thread for the following question:
I see that in btrfs_cross_ref_exist()=check_committed_ref() path,
there is the following check:
if (btrfs_extent_generation(leaf,
On Sun, Mar 3, 2013 at 10:41 AM, Aastha Mehta aasth...@gmail.com wrote:
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
Hi Josef,
I hope it's ok to piggy back on this thread for the following question:
I see that in btrfs_cross_ref_exist()=check_committed_ref() path,
there is the following check:
if (btrfs_extent_generation(leaf, ei) =
btrfs_root_last_snapshot(root-root_item))
goto out;
So this
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
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
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
A gentle reminder on this one.
Thanks,
Aastha.
On 21 February 2013 18:32, Aastha Mehta aasth...@gmail.com 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?
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
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
13 matches
Mail list logo
