From: Hugo Mills <hugo@carfax.org.uk>
To: Santosh Hosamani <Santosh_Hosamani@mindtree.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Bug in btrfs-debug-tree for two or more devices.
Date: Tue, 12 Jun 2012 21:06:50 +0100 [thread overview]
Message-ID: <20120612200650.GA28932@carfax.org.uk> (raw)
In-Reply-To: <24763ECA27C26742BD79B0D67389CD0E071B3067@MTW02MBX05.mindtree.com>
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
On Tue, Jun 12, 2012 at 06:53:00AM +0000, Santosh Hosamani wrote:
>
> Hi btrfs folks,
> I am working on btrfs filesystem on how it manages the free space. And found out btrfs maintain a ctree which manages the physical location of the chunks and stripes of the filesystem.
> Btrfs-debug-tree also gives the information on the chunk tree
>
> I created btrfs on single device and two device.I have attached the output of both on running btrfs-debug-tree.
> For single device sum of all the length in the chunks will add upto the total used bytes which is expected behavior.
>
> But for two devices sum of all lengths in the chunks does not add to the total bytes .Am I missing something .
Without actually seeing the details of your technique and
expectations, I shall make a guess that you're not accounting for the
double-counting of RAID-1 metadata. In other words, you will find that
all of the metadata device extents (or chunks) will appear twice --
once on each device.
Actually, this isn't quite right either -- what you really need to
do is look at the RAID-1, RAID-10 and DUP bits in the chunk flags, add
up all of those chunks, divide by two, and then add in the remaining
(RAID-0 and single) chunks. That total should then add up to the total
value of allocated space that you get from the output of "btrfs fi df".
> Also I notice that for the second device the superblock location 0x10000 is not considered as used .
>
> I would be really grateful if you folks can answer my query.
>
> I hav run these tests on SLES11-sp2-x86
> Kernel 3.0.13.0.27-default
This is pretty old, but shouldn't affect the results. It will cause
reliability problems if you try running it seriously.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- "There's a Martian war machine outside -- they want to talk ---
to you about a cure for the common cold."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2012-06-12 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 6:53 Bug in btrfs-debug-tree for two or more devices Santosh Hosamani
2012-06-12 14:57 ` Randy Barlow
2012-06-13 8:43 ` Santosh Hosamani
2012-06-12 15:22 ` Duncan
2012-06-12 16:49 ` Arne Jansen
2012-06-13 4:39 ` Santosh Hosamani
2012-06-12 20:06 ` Hugo Mills [this message]
2012-06-13 8:40 ` Santosh Hosamani
2012-06-12 22:58 ` David Sterba
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=20120612200650.GA28932@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=Santosh_Hosamani@mindtree.com \
--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).