public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian von Bidder <avbidder@fortytwo.ch>
To: linux-btrfs@vger.kernel.org
Subject: slow umount + btrfs-show odditiy
Date: Mon, 28 Dec 2009 15:59:46 +0100	[thread overview]
Message-ID: <200912281559.52522@fortytwo.ch> (raw)

[-- Attachment #1: Type: text/plain, Size: 4021 bytes --]

Heyho!

Running btrfs on a QNAP (ARM Platform), 1.8T Filesystem on most of 4 x 500G 
disks, raid 1 for data + metadata.  Filled with 300G files (dirvish trees, 
so lots of hardlinks.  Files are backups of "normal" user + root filesystems 
of a few PCs, so quite a mix in filesizes.)

[[[ Eventually I'll want to replace dirvish by plain rsync and use btrfs 
timestamps to get snapshots.  Got to prove stability first. ]]]

After copying the files from the prvevious location onto this filesystem, 
btrfs-show shows only 450G used on one disk and 30G or so on the other three 
disks (sorry, didn't preserve the output.)  In any case, the other three 
disks didn't have enough to contain all the data duplicated in raid1 
fashion.

"btrfs-vol -b" (obviously took quite some hours), now I have:

+++
Label: none  uuid: 9a41b0eb-3f9b-4f56-852e-13068829f8aa
        Total devices 4 FS bytes used 393.45GB
        devid    3 size 450.49GB used 389.00GB path /dev/sdc2
        devid    4 size 450.49GB used 396.01GB path /dev/sdd2
        devid    1 size 450.49GB used 396.01GB path /dev/sda2
        devid    5 size 450.49GB used 253.00GB path /dev/sdb2

Btrfs v0.19-4-gab8fb4c-dirty
+++

Which is strange as well.  Given that the real data is ~400G, I'd have 
expected the disks to be fileed with 4 x 200G plus some metadata, but this 
looks like almost twice as much as I'd expect.

I'm no fs debugger, so it might be anything of
 -> btrfs-show is far off
 -> metadata on btrfs is quite big
 -> I don't have raid1 (data + metadata mirrored inn two places) but the 
stuff is being mirrored on more disks than necessary.
 -> or something completely different...


And after that, umount took about 5min (the machine has only 512M, and I 
waited a few hours after "btrfs-vol -b" has completed before I unmounted, 
but I did not issue a sync first.)

The kernel triggered twice or so with the following:


Dec 28 15:45:08 syydelaervli kernel: [97580.340641] INFO: task umount:12765 blocked for more than 120 seconds.
Dec 28 15:45:08 syydelaervli kernel: [97580.340674] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 28 15:45:08 syydelaervli kernel: [97580.340699] umount        D c02b080c     0 12765  12681 0x00000000
Dec 28 15:45:08 syydelaervli kernel: [97580.340749] [<c02b080c>] (schedule+0x424/0x488) from [<c00e719c>] (bdi_sched_wait+0xc/0x18)
Dec 28 15:45:08 syydelaervli kernel: [97580.340787] [<c00e719c>] (bdi_sched_wait+0xc/0x18) from [<c02b0f68>] (__wait_on_bit+0x5c/0xa8)
Dec 28 15:45:08 syydelaervli kernel: [97580.340821] [<c02b0f68>] (__wait_on_bit+0x5c/0xa8) from [<c02b1060>] 
(out_of_line_wait_on_bit+0xac/0xc4)
Dec 28 15:45:08 syydelaervli kernel: [97580.340857] [<c02b1060>] (out_of_line_wait_on_bit+0xac/0xc4) from [<c00e7210>] 
(sync_inodes_sb+0x68/0x100)
Dec 28 15:45:08 syydelaervli kernel: [97580.340894] [<c00e7210>] (sync_inodes_sb+0x68/0x100) from [<c00eb340>] (__sync_filesystem+0x64/0x94)
Dec 28 15:45:08 syydelaervli kernel: [97580.340932] [<c00eb340>] (__sync_filesystem+0x64/0x94) from [<c00cdc74>] 
(generic_shutdown_super+0x28/0x110)
Dec 28 15:45:08 syydelaervli kernel: [97580.340970] [<c00cdc74>] (generic_shutdown_super+0x28/0x110) from [<c00cdda8>] 
(kill_anon_super+0x14/0x3c)
Dec 28 15:45:08 syydelaervli kernel: [97580.341008] [<c00cdda8>] (kill_anon_super+0x14/0x3c) from [<c00ce46c>] (deactivate_super+0x6c/0x90)
Dec 28 15:45:08 syydelaervli kernel: [97580.341044] [<c00ce46c>] (deactivate_super+0x6c/0x90) from [<c00e2310>] (sys_umount+0x2bc/0x2e8)
Dec 28 15:45:08 syydelaervli kernel: [97580.341079] [<c00e2310>] (sys_umount+0x2bc/0x2e8) from [<c0026ea0>] (ret_fast_syscall+0x0/0x28)

Other than that, the umount succeeded, I can mount the fs again and work on that fs.

This all with btrfs as it comes in 2.6.32.

Ok, I guess that's it for now.

cheers
-- vbi




-- 
Leute, die immer nur mitfahren, sind stolz darauf, keine Unfälle zu
verschulden.
		-- Gabriel Laub

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 389 bytes --]

                 reply	other threads:[~2009-12-28 14:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200912281559.52522@fortytwo.ch \
    --to=avbidder@fortytwo.ch \
    --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