Okay, that makes lot more sense to me now.
Thank you very much.
Regards,
Aastha.
On 5 March 2013 02:51, Josef Bacik wrote:
> On Mon, Mar 4, 2013 at 7:57 PM, Aastha Mehta wrote:
>> I must admit, it is quite convoluted :-)
>>
>> Please tell me if I understand this. A file system tree (containing
On Mon, Mar 4, 2013 at 7:57 PM, Aastha Mehta 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, which is the root
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 m
On Sun, Mar 3, 2013 at 10:41 AM, Aastha Mehta 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 data extent wr
On Sat, Mar 2, 2013 at 4:07 PM, Alex Lyakas
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, ei) <=
> btrfs_r
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 up
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 ba
Ah okay, I now see how it works. Thanks a lot for your response.
Regards,
Aastha.
On 25 February 2013 18:27, Josef Bacik 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
>>
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
>
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
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
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_wr
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
13 matches
Mail list logo
