Thank you Jan, Hugo & Lio,
for taking time answering my questions.
Alex.
P.S.: I have dug in some more, so probably more questions will arrive:)
On Tue, May 29, 2012 at 12:13 PM, Jan Schmidt wrote:
> On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
>> I have re-looked at btrfs_search_s
On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
> I have re-looked at btrfs_search_slot, and don't see how it would end
> up in leaf B. The bin_search() function will clearly return the slot
> *after* the slot of N that has key==5 (which is the parent slot of A).
> So then the following c
Hi Jan,
>> Let's say that slot[0] of the current leaf (A) has key=10. And let's
>> say that its parent node (N) has key=5 (and not 10). Let's say we have
>> a previous leaf (B), whose last slot has key=2.
>> If such tree is valid, then: btrfs_prev_leaf() will search for key==9.
>> Then btrfs_searc
On 22.05.2012 10:07, Alex Lyakas wrote:
>>> # If my understanding in the previous bullet is correct: Is that the
>>> reason that in btrfs_prev_leaf() it is assumed that if there is a
>>> lesser key, btrfs_search_slot() will never bring us to the slot==0 of
>>> the current leaf?
>>
>> It's quite str
Hi Jan,
>> # I saw that slot==0 is special. My understanding is that btrfs
>> maintains the property that the parent of each node/leaf has a key
>> pointing to that node/leaf, which must be equal to the key in the
>> slot==0 of this node/leaf. That's what fixup_low_keys() tries to
>> maintain. Is
Thanks, Liu, that clarifies.
Alex.
On Tue, May 22, 2012 at 4:42 AM, Liu Bo wrote:
> On 05/21/2012 06:05 PM, Alex Lyakas wrote:
>
>> Hi Liu,
>> thanks for the clarifications.
>>
>> I did not understand the dd example of yours, though.
>>
>>> So for the following situation:
item 23 key
On 05/21/2012 06:05 PM, Alex Lyakas wrote:
> Hi Liu,
> thanks for the clarifications.
>
> I did not understand the dd example of yours, though.
>
>> So for the following situation:
>>> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
>>> extent data disk byte 0 nr
Hi Alex,
On Fri, May 18, 2012 at 13:21 (+0200), Alex Lyakas wrote:
> Some general questions on the ctree code.
>
> # I saw that slot==0 is special. My understanding is that btrfs
> maintains the property that the parent of each node/leaf has a key
> pointing to that node/leaf, which must be equal
Hi Liu,
thanks for the clarifications.
I did not understand the dd example of yours, though.
> So for the following situation:
>> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
>> extent data disk byte 0 nr 0
>> extent data offset 0 nr 4096 ram 8192
On 05/21/2012 04:20 PM, Alex Lyakas wrote:
> Hi Liu,
> do you think that this should not happen? I see this all the time, and
> I am not doing any stress tests. Just creating a file and writing some
> data at different offsets, to create "holes" in the file offset space.
> btrfsck does not produce
Hi Liu,
do you think that this should not happen? I see this all the time, and
I am not doing any stress tests. Just creating a file and writing some
data at different offsets, to create "holes" in the file offset space.
btrfsck does not produce any errors.
I am using kernel 3.3.6 and btrfs-progrs
On 05/18/2012 09:32 PM, Alex Lyakas wrote:
> Thank you, Hugo, for the detailed explanation. I am now able to find
> the CHUNK_ITEMs and to successfully locate the file data on disk.
> Can you maybe address several follow-up questions I have?
>
> # When looking for CHUNK_ITEMs, should I check that
Hugo,
thanks for helping out!
Hopefully, somebody else will address the rest of my questions.
Alex.
On Fri, May 18, 2012 at 4:59 PM, Hugo Mills wrote:
> On Fri, May 18, 2012 at 04:32:09PM +0300, Alex Lyakas wrote:
>> Thank you, Hugo, for the detailed explanation. I am now able to find
>> the CH
On Fri, May 18, 2012 at 04:32:09PM +0300, Alex Lyakas wrote:
> Thank you, Hugo, for the detailed explanation. I am now able to find
> the CHUNK_ITEMs and to successfully locate the file data on disk.
> Can you maybe address several follow-up questions I have?
>
> # When looking for CHUNK_ITEMs, sh
Thank you, Hugo, for the detailed explanation. I am now able to find
the CHUNK_ITEMs and to successfully locate the file data on disk.
Can you maybe address several follow-up questions I have?
# When looking for CHUNK_ITEMs, should I check that their
btrfs_chunk::type==BTRFS_BLOCK_GROUP_DATA (and
On Fri, May 18, 2012 at 02:21:59PM +0300, Alex Lyakas wrote:
> Greetings everybody,
> I have been studying some of the btrfs code and the developer
> documentation on the wiki. My primary interest at this point, is to be
> able to search within fs tree of a btrfs subvolume, which was created
> as a
Greetings everybody,
I have been studying some of the btrfs code and the developer
documentation on the wiki. My primary interest at this point, is to be
able to search within fs tree of a btrfs subvolume, which was created
as a snapshot of another subvolume. For that I have been using the
debug-tr
17 matches
Mail list logo
