From: Lee Trager <lt73@cs.drexel.edu>
To: "Mitch Harder (aka DontPanic)" <mmharder@gmail.com>
Cc: Hugo Mills <hugo-lkml@carfax.org.uk>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Mason <chris.mason@oracle.com>
Subject: Re: btrfs: warn_slowpath in clean_tree_block and others
Date: Wed, 25 Feb 2009 01:26:45 -0500 [thread overview]
Message-ID: <49A4E4A5.7040103@cs.drexel.edu> (raw)
In-Reply-To: <89ed0c690902242022u526bb9bn5e7a8682ac0c0a96@mail.gmail.com>
Mitch, I haven't seen any problems using BTRFS and my patch on 2.6.28 or
2.6.27, what are you doing to cause this error? Are you using the latest
sources from btrfs-unstable?
Lee
Mitch Harder (aka DontPanic) wrote:
> I have also been getting similar warnings filling up my logs.
>
> However, in my case, I have been experimenting with back-porting btrfs
> to a 2.6.28 kernel. So I've been waiting for the back-porting efforts
> to get a little further along.
>
> But I thought I'd respond in case this information helps.
>
> Here's an example of the warnings I've been seeing:
>
> [80577.151167] ------------[ cut here ]------------
> [80577.151169] WARNING: at
> /var/tmp/portage/sys-fs/btrfs-9998/work/btrfs-9998/disk-io.c:860
> clean_tree_block+0xa4/0xb0 [btrfs]()
> [80577.151172] Modules linked in: btrfs snd_pcm_oss snd_mixer_oss
> snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
> ipv6 ppdev snd_intel8x0 snd_ac97_codec parport_pc nvidia(P) ac97_bus
> snd_pcm snd_timer ohci_hcd ssb shpchp pci_hotplug pcmcia i2c_nforce2
> snd forcedeth sr_mod pcspkr parport i2c_core snd_page_alloc nvidia_agp
> sl811_hcd pcmcia_core uhci_hcd ehci_hcd
> [80577.151190] Pid: 11503, comm: cp Tainted: P W 2.6.28-sabayon-r10 #1
> [80577.151192] Call Trace:
> [80577.151195] [<c011e77f>] warn_on_slowpath+0x5f/0x90
> [80577.151203] [<c043c427>] rb_insert_color+0x77/0xe0
> [80577.151221] [<f8c28e9e>] alloc_extent_buffer+0x1fe/0x300 [btrfs]
> [80577.151238] [<f8c08d54>] clean_tree_block+0xa4/0xb0 [btrfs]
> [80577.151253] [<f8bf665d>] btrfs_init_new_buffer+0x7d/0x130 [btrfs]
> [80577.151269] [<f8bfb6f4>] btrfs_alloc_free_block+0x104/0x110 [btrfs]
> [80577.151285] [<f8bef3da>] __btrfs_cow_block+0x22a/0x8b0 [btrfs]
> [80577.151300] [<f8bed212>] generic_bin_search+0x162/0x1c0 [btrfs]
> [80577.151315] [<f8bf00e6>] btrfs_cow_block+0x156/0x200 [btrfs]
> [80577.151330] [<f8bf3267>] btrfs_search_slot+0x1a7/0x910 [btrfs]
> [80577.151333] [<c01230e7>] irq_exit+0x27/0x60
> [80577.151336] [<c01052cb>] do_IRQ+0x6b/0x80
> [80577.151354] [<f8c24a55>] read_extent_buffer+0xd5/0x170 [btrfs]
> [80577.151369] [<f8bf3f7d>] btrfs_insert_empty_items+0x6d/0x410 [btrfs]
> [80577.151385] [<f8bf8f4f>] btrfs_find_block_group+0xff/0x1a0 [btrfs]
> [80577.151402] [<f8c0fa1d>] btrfs_new_inode+0x18d/0x360 [btrfs]
> [80577.151420] [<f8c135a9>] btrfs_create+0x189/0x2a0 [btrfs]
> [80577.151423] [<c04162d9>] security_capable+0x9/0x10
> [80577.151427] [<c0197f3d>] vfs_create+0xcd/0x160
> [80577.151430] [<c019ad6f>] do_filp_open+0x5af/0x7d0
> [80577.151433] [<c01932e9>] cp_new_stat64+0xf9/0x110
> [80577.151436] [<c018e40e>] do_sys_open+0x4e/0xe0
> [80577.151439] [<c018e51c>] sys_open+0x2c/0x40
> [80577.151442] [<c0103165>] sysenter_do_call+0x12/0x21
> [80577.151444] ---[ end trace 79cdc48bc88dedf7 ]---
>
>
> On Tue, Feb 24, 2009 at 5:02 PM, Hugo Mills <hugo-lkml@carfax.org.uk> wrote:
>
>> This is essentially a repost of a mail I made last week, to which I
>> didn't get a reply.
>>
>> I'm getting huge numbers of kernel warnings whilst using
>> btrfs. They're all "warn_slowpath", and all seem to be in
>> fs/btrfs/disk-io.c. I've included one typical example at the end of
>> this mail.
>>
>> Kernel versions are 2.6.29-rc2, -rc4 and -rc6.
>>
>> If I do lots of writes to my btrfs filesystem (e.g. video
>> encoding), I end up with a syslog in the tens-of-megabytes range. This
>> makes logcheck an unhappy bunny...
>>
>> I don't know if this behaviour is expected, and everyone using
>> btrfs simply puts up with it for now, or if it's something unusual
>> that needs investigating. On the chance that it's the latter, I'm
>> reporting it here.
>>
>> Hugo.
>>
>> Feb 23 21:45:42 vlad kernel: ------------[ cut here ]------------
>> Feb 23 21:45:42 vlad kernel: WARNING: at fs/btrfs/disk-io.c:815 clean_tree_block+0x9d/0xbb [btrfs]()
>> Feb 23 21:45:42 vlad kernel: Hardware name: System Product Name
>> Feb 23 21:45:42 vlad kernel: Modules linked in: tun ext3 jbd btrfs zlib_deflate tcp_diag inet_diag kqemu cpufreq_userspace ipv6 nfsd nfs lockd nfs_acl auth_rpcgss sunrpc af_packet bridge stp llc xfs exportfs it87 hwmon_vid powernow_k8 sbp2 ieee1394 ide_generic ide_gd_mod ide_cd_mod pcspkr evdev k8temp hwmon i2c_viapro i2c_core button dm_mirror dm_region_hash dm_log dm_snapshot dm_mod raid1 md_mod usbhid usb_storage libusual sg sr_mod cdrom via82cxxx floppy via_rhine mii ehci_hcd uhci_hcd usbcore pata_via ide_pci_generic ide_core sd_mod thermal processor fan unix
>> Feb 23 21:45:42 vlad kernel: Pid: 27034, comm: hdparm Tainted: G W 2.6.29-rc4 #1
>> Feb 23 21:45:42 vlad kernel: Call Trace:
>> Feb 23 21:45:42 vlad kernel: [<ffffffff80228d7d>] warn_slowpath+0xd8/0x111
>> Feb 23 21:45:42 vlad kernel: [<ffffffff80312f11>] radix_tree_insert+0xd7/0x19f
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8024d55d>] add_to_page_cache_locked+0x52/0x9e
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8024d5e9>] add_to_page_cache_lru+0x40/0x58
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8024dbd0>] find_or_create_page+0x62/0x88
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03f992a>] alloc_extent_buffer+0x268/0x2ec [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e1b18>] clean_tree_block+0x9d/0xbb [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d5eaf>] btrfs_init_new_buffer+0x99/0xf3 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d849e>] btrfs_alloc_free_block+0x83/0x8c [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cb2f8>] __btrfs_cow_block+0x1ff/0x87e [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cc125>] btrfs_cow_block+0x1e7/0x1f6 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffff80251d9e>] __alloc_pages_internal+0xd2/0x3ec
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d0915>] btrfs_search_slot+0x36f/0x99b [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d14ee>] btrfs_insert_empty_items+0x7f/0x49d [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d825d>] __btrfs_alloc_reserved_extent+0x19f/0x2bb [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d83f0>] btrfs_alloc_extent+0x77/0xa2 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d847f>] btrfs_alloc_free_block+0x64/0x8c [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cb2f8>] __btrfs_cow_block+0x1ff/0x87e [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d7532>] finish_current_insert+0x514/0x528 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d7bf9>] del_pending_extents+0xa5/0x33d [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cc125>] btrfs_cow_block+0x1e7/0x1f6 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e436d>] btrfs_commit_tree_roots+0x53/0x1ba [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffff80403a3e>] schedule_timeout+0xa1/0xbc
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e55dd>] btrfs_commit_transaction+0x322/0x6e5 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffff802385fb>] autoremove_wake_function+0x0/0x2e
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e4809>] join_transaction+0x129/0x147 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03c8788>] btrfs_sync_fs+0x70/0x78 [btrfs]
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8026f332>] sync_filesystems+0xa8/0xde
>> Feb 23 21:45:42 vlad kernel: [<ffffffff80287256>] do_sync+0x25/0x50
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8028728f>] sys_sync+0xe/0x13
>> Feb 23 21:45:42 vlad kernel: [<ffffffff8020b25b>] system_call_fastpath+0x16/0x1b
>> Feb 23 21:45:42 vlad kernel: ---[ end trace a315082d564863a6 ]---
>>
>>
>> --
>> === 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
>> --- Eighth Army Push Bottles Up Germans -- WWII newspaper ---
>> headline (possibly apocryphal)
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iD8DBQFJpHyZIKyzvlFcI40RApVLAJoDrHaA+9cebRyJDm+vhGqgEQGiMACguCV+
>> znRCpat0ajek+ivXViQX5rg=
>> =GsHM
>> -----END PGP SIGNATURE-----
>>
>>
>>
> --
> 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
>
next prev parent reply other threads:[~2009-02-25 6:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 23:02 btrfs: warn_slowpath in clean_tree_block and others Hugo Mills
2009-02-25 4:22 ` Mitch Harder (aka DontPanic)
2009-02-25 4:22 ` Mitch Harder (aka DontPanic)
2009-02-25 6:26 ` Lee Trager [this message]
[not found] ` <89ed0c690902250603g2f6236d6q3be2f2f065ea0df@mail.gmail.com>
2009-02-25 16:05 ` Lee Trager
2009-02-25 16:13 ` Hugo Mills
2009-02-25 16:16 ` Mitch Harder (aka DontPanic)
2009-02-25 18:36 ` Chris Mason
2009-02-25 18:54 ` Hugo Mills
[not found] ` <89ed0c690902251050g1e6dd23ay5d5426adb7086018@mail.gmail.com>
2009-02-25 19:26 ` Chris Mason
2009-02-25 21:41 ` Hugo Mills
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=49A4E4A5.7040103@cs.drexel.edu \
--to=lt73@cs.drexel.edu \
--cc=chris.mason@oracle.com \
--cc=hugo-lkml@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmharder@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.