From: Alexander Skwar <alexanders.mailinglists+nospam@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]()
Date: Tue, 30 Apr 2013 11:51:17 +0000 (UTC) [thread overview]
Message-ID: <loom.20130430T133556-803@post.gmane.org> (raw)
In-Reply-To: 20130430094131.GA8274@carfax.org.uk
Hugo Mills <hugo <at> carfax.org.uk> writes:
> The differences in btrfs between the two are very small, and even
> I(*) wouldn't call 3.8.0 "very old" quite yet, given that 3.9 was only
> released yesterday. From memory, there's one btrfs patch in the 3.8
> stable series.
>
> Your problem is "just" a warning, and appears to be something to do
> with running out of space, or having too many CRCs... I don't really
> know the free space cache code at all well, so I'm mostly guessing
> here, from looking at the WARN_ON in __btrfs_write_out_cache.
Yes, I'm aware that this just a warning, but I'm a bit scared
because of the big number of those warnings.
FWIW, I also got that exact same kernel trace on the Ubuntu
kernel 3.5.0-28-lowlatency; see http://pastebin.com/rmPAqcTu or here:
------------[ cut here ]------------
WARNING: at fs/btrfs/free-space-cache.c:922
__btrfs_write_out_cache+0x6b9/0x990 [btrfs]()
Hardware name: HP Compaq dc5800 Microtower
Modules linked in: btrfs zlib_deflate libcrc32c des_generic md4 nvidia(PO)
snd_hda_codec_analog arc4 tpm_infineon coretemp snd_hda_intel rtl8192cu
snd_hda_codec kvm_intel rtl8192c_common rtlwifi kvm snd_hwdep snd_pcm
parport_pc snd_seq_midi bnep rfcomm mac80211 ppdev snd_rawmidi bluetooth
snd_seq_midi_event snd_seq binfmt_misc snd_timer snd_seq_device cfg80211
dm_multipath psmouse hp_wmi snd scsi_dh gpio_ich sparse_keymap soundcore
microcode serio_raw tpm_tis mei mac_hid snd_page_alloc wmi lpc_ich lp
parport nls_utf8 cifs fscache ext2 hid_generic usbhid hid usb_storage floppy
e1000e
Pid: 25834, comm: btrfs Tainted: P O 3.5.0-28-lowlatency #31-
Ubuntu
Call Trace:
[<ffffffff81053d5f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff81053dba>] warn_slowpath_null+0x1a/0x20
[<ffffffffa0f83fd9>] __btrfs_write_out_cache+0x6b9/0x990 [btrfs]
[<ffffffffa0f29325>] ? __find_space_info+0x85/0xa0 [btrfs]
[<ffffffff8168f76e>] ? _raw_spin_unlock+0xe/0x40
[<ffffffffa0f32fbc>] ? btrfs_run_delayed_refs+0x1ec/0x470 [btrfs]
[<ffffffffa0f84345>] btrfs_write_out_cache+0x95/0xf0 [btrfs]
[<ffffffffa0f3375f>] btrfs_write_dirty_block_groups+0x51f/0x5f0 [btrfs]
[<ffffffffa0f9edc2>] commit_cowonly_roots+0xfd/0x1c7 [btrfs]
[<ffffffffa0f94121>] ? btrfs_run_delayed_items+0xd1/0x150 [btrfs]
[<ffffffffa0f44725>] btrfs_commit_transaction+0x5d5/0xb00 [btrfs]
[<ffffffff81078ff0>] ? finish_wait+0x80/0x80
[<ffffffff8119f122>] ? __d_instantiate+0xd2/0x110
[<ffffffff812bf11b>] ? security_d_instantiate+0x1b/0x30
[<ffffffffa0f9f8ab>] create_subvol+0x4d1/0x4f8 [btrfs]
[<ffffffffa0f794e5>] btrfs_mksubvol+0x3a5/0x400 [btrfs]
[<ffffffffa0f795fe>] btrfs_ioctl_snap_create_transid+0xbe/0x180 [btrfs]
[<ffffffffa0f79716>] btrfs_ioctl_snap_create+0x56/0x80 [btrfs]
[<ffffffffa0f7baba>] btrfs_ioctl+0xc0a/0x1280 [btrfs]
[<ffffffff81692b84>] ? do_page_fault+0x1b4/0x4b0
[<ffffffff8119b307>] do_vfs_ioctl+0x97/0x530
[<ffffffff811898c5>] ? vfs_write+0x105/0x180
[<ffffffff8119b839>] sys_ioctl+0x99/0xa0
[<ffffffff8169081e>] ? do_device_not_available+0xe/0x10
[<ffffffff816969e9>] system_call_fastpath+0x16/0x1b
---[ end trace fadd80d2b7f6ec9f ]---
Both traces (from 3.8.0 and 3.5.0) are in fs/btrfs/free-space-cache.c
and have warn_slowpath_common as the first function. Strange, isn't
it?
Since the problem exists for a long time, I pretty much doubt that
just updating the kernel source would help. I'd rather not, I'd
rather stay with the kernel of my distribution.
I should have mentioned in my OP, that the btrfs is on a LVM. Right
now, I've got two distinct btrfs filesystems on the system; both
on LVM and on seperate logical volumes.
I get this kernel trace / warning only on one of these filesystems.
The LV existed also "back in kernel 3.5.0 times". I've since ran
a btrfs scrub, but it didn't find any errors:
a@ewzw032:~$ sudo btrfs scrub status -d /data
scrub status for 8009e99c-726d-46fb-b68c-be57fb66ca05
scrub device /dev/mapper/system-Data (id 1) history
scrub started at Tue Apr 30 08:55:27 2013 and finished after 2989
seconds
total bytes scrubbed: 146.82GB with 0 errors
a@ewzw032:~$ sudo btrfs scrub status -R /data
scrub status for 8009e99c-726d-46fb-b68c-be57fb66ca05
scrub started at Tue Apr 30 08:55:27 2013 and finished after 2989
seconds
data_extents_scrubbed: 2564422
tree_extents_scrubbed: 107996
data_bytes_scrubbed: 157200080896
tree_bytes_scrubbed: 442351616
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 0
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 251959246848
Best regards,
Alexander
next prev parent reply other threads:[~2013-04-30 11:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 6:37 WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]() Alexander Skwar
2013-04-30 6:55 ` Helmut Hullen
2013-04-30 9:41 ` Hugo Mills
2013-04-30 11:51 ` Alexander Skwar [this message]
2013-04-30 13:58 ` Josef Bacik
2013-04-30 14:33 ` Alexander Skwar
2013-04-30 17:53 ` Josef Bacik
2013-05-01 6:39 ` Alexander Skwar
2013-05-01 18:57 ` Josef Bacik
2013-05-01 19:19 ` Jon Nelson
2013-05-01 20:08 ` Alexander Skwar
[not found] ` <CADn-QaPh9EZjnbr9HoRKTMi8OUgnvfRdD7riEDZ0hpkcNRN93Q@mail.gmail.com>
2013-05-08 20:40 ` Josef Bacik
2013-05-08 20:47 ` Josef Bacik
2013-05-13 8:33 ` Alexander Skwar
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=loom.20130430T133556-803@post.gmane.org \
--to=alexanders.mailinglists+nospam@gmail.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