linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu Bo <liubo2009@cn.fujitsu.com>
To: Alex Lyakas <alex.bolshoy.btrfs@gmail.com>
Cc: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Newbie questions on some of btrfs code...
Date: Mon, 21 May 2012 09:59:36 +0800	[thread overview]
Message-ID: <4FB9A188.9090403@cn.fujitsu.com> (raw)
In-Reply-To: <CAHf9xva5ux5VXbww2YMjORSSdhSKH7L6W5vbP-ZnxijiGK4fUw@mail.gmail.com>

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 their
> btrfs_chunk::type==BTRFS_BLOCK_GROUP_DATA (and not SYSTEM/METADATA
> etc)? Or file extent should always be mapped to BTRFS_BLOCK_GROUP_DATA
> chunk?
> 
> # It looks like I don't even need to bother with the extent tree at
> this point, because from EXTENT_DATA in fs tree I can navigate
> directly to CHUNK_ITEM in chunk tree, correct?
> 
> # For replicating RAID levels, you said there will be multiple
> CHUNK_ITEMs. How do I find them then? Should I know in advance how
> much there should be, and look for them, considering only
> btrfs_chunk::type==BTRFS_BLOCK_GROUP_DATA? (I don't bother for
> replication at this point, though).
> 
> # If I find in the fs tree an EXTENT_DATA of type
> BTRFS_FILE_EXTENT_PREALLOC, how should I treat it? What does it mean?
> (BTRFS_FILE_EXTENT_INLINE are easy to treat).
> 
> # One of my files has two EXTENT_DATAs, like this:
> 	item 14 key (270 EXTENT_DATA 0) itemoff 1812 itemsize 53
> 		extent data disk byte 432508928 nr 1474560
> 		extent data offset 0 nr 1470464 ram 1474560
> 		extent compression 0
> 	item 15 key (270 EXTENT_DATA 1470464) itemoff 1759 itemsize 53
> 		extent data disk byte 432082944 nr 126976
> 		extent data offset 0 nr 126976 ram 126976
> 		extent compression 0
> Summing btrfs_file_extent_item::num_bytes gives
> 1470464+126976=1597440. (I know that I should not be summing
> btrfs_file_extent_item::disk_num_bytes, but num_bytes).
> However, it's INODE_ITEM gives size of 1593360, which is less:
> 	item 11 key (270 INODE_ITEM 0) itemoff 1970 itemsize 160
> 		inode generation 26 size 1593360 block group 0 mode 100700 links 1
> 
> Is this a valid situation, or I should always consider size in
> INODE_ITEM as the correct one?
> 


Hi Alex,

Have you tried btrfsck on this 'inode size mismatch' box?

And I'm interest in if it can be reproduced and how?


thanks,
liubo

> Thanks again,
> Alex.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



  parent reply	other threads:[~2012-05-21  1:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 11:21 Newbie questions on some of btrfs code Alex Lyakas
2012-05-18 11:50 ` Hugo Mills
2012-05-18 13:32   ` Alex Lyakas
2012-05-18 13:59     ` Hugo Mills
2012-05-20  7:40       ` Alex Lyakas
2012-05-21  1:59     ` Liu Bo [this message]
2012-05-21  8:20       ` Alex Lyakas
2012-05-21  9:33         ` Liu Bo
2012-05-21 10:05           ` Alex Lyakas
2012-05-22  1:42             ` Liu Bo
2012-05-22  7:48               ` Alex Lyakas
2012-05-21 10:44 ` Jan Schmidt
2012-05-22  8:07   ` Alex Lyakas
2012-05-22 22:08     ` Jan Schmidt
2012-05-28 18:45       ` Alex Lyakas
2012-05-29  9:13         ` Jan Schmidt
2012-05-29 11:27           ` Alex Lyakas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB9A188.9090403@cn.fujitsu.com \
    --to=liubo2009@cn.fujitsu.com \
    --cc=alex.bolshoy.btrfs@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).