btrfs: warn_slowpath in clean_tree_block and others

btrfs: warn_slowpath in clean_tree_block and others

[Hugo Mills]

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

   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)                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: btrfs: warn_slowpath in clean_tree_block and others

[Mitch Harder (aka DontPanic)]

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> w=
rote:
> =A0 This is essentially a repost of a mail I made last week, to which=
 I
> didn't get a reply.
>
> =A0 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.
>
> =A0 Kernel versions are 2.6.29-rc2, -rc4 and -rc6.
>
> =A0 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. Thi=
s
> makes logcheck an unhappy bunny...
>
> =A0 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.
>
> =A0 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 zl=
ib_deflate tcp_diag inet_diag kqemu cpufreq_userspace ipv6 nfsd nfs loc=
kd nfs_acl auth_rpcgss sunrpc af_packet bridge stp llc xfs exportfs it8=
7 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_regi=
on_hash dm_log dm_snapshot dm_mod raid1 md_mod usbhid usb_storage libus=
ual sg sr_mod cdrom via82cxxx floppy via_rhine mii ehci_hcd uhci_hcd us=
bcore pata_via ide_pci_generic ide_core sd_mod thermal processor fan un=
ix
> Feb 23 21:45:42 vlad kernel: Pid: 27034, comm: hdparm Tainted: G =A0 =
=A0 =A0 =A0W =A02.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+0=
xd7/0x19f
> Feb 23 21:45:42 vlad kernel: [<ffffffff8024d55d>] add_to_page_cache_l=
ocked+0x52/0x9e
> Feb 23 21:45:42 vlad kernel: [<ffffffff8024d5e9>] add_to_page_cache_l=
ru+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+0x=
9d/0xbb [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d5eaf>] btrfs_init_new_buff=
er+0x99/0xf3 [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d849e>] btrfs_alloc_free_bl=
ock+0x83/0x8c [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cb2f8>] __btrfs_cow_block+0=
x1ff/0x87e [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cc125>] btrfs_cow_block+0x1=
e7/0x1f6 [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffff80251d9e>] __alloc_pages_inter=
nal+0xd2/0x3ec
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d0915>] btrfs_search_slot+0=
x36f/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_reser=
ved_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_bl=
ock+0x64/0x8c [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03cb2f8>] __btrfs_cow_block+0=
x1ff/0x87e [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d7532>] finish_current_inse=
rt+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+0x1=
e7/0x1f6 [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e436d>] btrfs_commit_tree_r=
oots+0x53/0x1ba [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffff80403a3e>] schedule_timeout+0x=
a1/0xbc
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e55dd>] btrfs_commit_transa=
ction+0x322/0x6e5 [btrfs]
> Feb 23 21:45:42 vlad kernel: [<ffffffff802385fb>] autoremove_wake_fun=
ction+0x0/0x2e
> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e4809>] join_transaction+0x=
129/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+0x=
a8/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_fastpat=
h+0x16/0x1b
> Feb 23 21:45:42 vlad kernel: ---[ end trace a315082d564863a6 ]---
>
>
> --
> =3D=3D=3D Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.=
org.uk =3D=3D=3D
> =A0PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org=
=2Euk
> =A0 =A0 =A0--- Eighth Army Push Bottles Up Germans -- WWII newspaper =
---
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 headline (possibly apocryphal=
)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJpHyZIKyzvlFcI40RApVLAJoDrHaA+9cebRyJDm+vhGqgEQGiMACguCV+
> znRCpat0ajek+ivXViQX5rg=3D
> =3DGsHM
> -----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

Re: btrfs: warn_slowpath in clean_tree_block and others

[Lee Trager]

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
>   

Re: btrfs: warn_slowpath in clean_tree_block and others

[Lee Trager]

But what are you doing to the filesystem when it crashes? How did you
mount it?

Lee

On Wed, Feb 25, 2009 at 08:03:01AM -0600, Mitch Harder (aka DontPanic) wrote:
> I've been creating a local git repository of full btrfs-unstable sources.
> 
> I'll create a new branch off the master branch, and apply the patch
> supplied in the Feb. 11 message to the M/L.
> 
> I then create a kernel module based on the results in /fs/btrfs/
> 
> I have also tried replicating the experimental branch, and merging the
> patch into that branch, but I get the same results.
> 
> On Wed, Feb 25, 2009 at 12:26 AM, Lee Trager <lt73@cs.drexel.edu> wrote:
> > 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
> >>
> >
> >

Re: btrfs: warn_slowpath in clean_tree_block and others

[Hugo Mills]

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

On Wed, Feb 25, 2009 at 11:05:58AM -0500, Lee Trager wrote:
> But what are you doing to the filesystem when it crashes? How did you
> mount it?

   In my case, it's mounted with this fstab entry:

/dev/media/scratch      /media/vlad/video/video btrfs   noatime,nosuid,nodev         0 0

and I can trigger hundreds (literally) of these backtraces with a
single "touch /media/vlad/video/video/foo". If I encode a video to the
FS, the backtraces come in bursts at intervals of, say, 20 seconds
(it's not perfectly regular).

   Hugo.

> On Wed, Feb 25, 2009 at 08:03:01AM -0600, Mitch Harder (aka DontPanic) wrote:
> > I've been creating a local git repository of full btrfs-unstable sources.
> > 
> > I'll create a new branch off the master branch, and apply the patch
> > supplied in the Feb. 11 message to the M/L.
> > 
> > I then create a kernel module based on the results in /fs/btrfs/
> > 
> > I have also tried replicating the experimental branch, and merging the
> > patch into that branch, but I get the same results.
> > 
> > On Wed, Feb 25, 2009 at 12:26 AM, Lee Trager <lt73@cs.drexel.edu> wrote:
> > > 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
      --- UNIX: British manufacturer of modular shelving units. ---      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: btrfs: warn_slowpath in clean_tree_block and others

[Mitch Harder (aka DontPanic)]

The messages attached are only "WARNING" messages.

I have not been encountering a crash, nor does the data seem to get
corrupted in my case (as far as I can tell).

Btrfs seems to actually work fine, except for the large amount of log m=
essages.

On Wed, Feb 25, 2009 at 10:13 AM, Hugo Mills <hugo-lkml@carfax.org.uk> =
wrote:
> On Wed, Feb 25, 2009 at 11:05:58AM -0500, Lee Trager wrote:
>> But what are you doing to the filesystem when it crashes? How did yo=
u
>> mount it?
>
> =A0 In my case, it's mounted with this fstab entry:
>
> /dev/media/scratch =A0 =A0 =A0/media/vlad/video/video btrfs =A0 noati=
me,nosuid,nodev =A0 =A0 =A0 =A0 0 0
>
> and I can trigger hundreds (literally) of these backtraces with a
> single "touch /media/vlad/video/video/foo". If I encode a video to th=
e
> FS, the backtraces come in bursts at intervals of, say, 20 seconds
> (it's not perfectly regular).
>
> =A0 Hugo.
>
>> On Wed, Feb 25, 2009 at 08:03:01AM -0600, Mitch Harder (aka DontPani=
c) wrote:
>> > I've been creating a local git repository of full btrfs-unstable s=
ources.
>> >
>> > I'll create a new branch off the master branch, and apply the patc=
h
>> > supplied in the Feb. 11 message to the M/L.
>> >
>> > I then create a kernel module based on the results in /fs/btrfs/
>> >
>> > I have also tried replicating the experimental branch, and merging=
 the
>> > patch into that branch, but I get the same results.
>> >
>> > On Wed, Feb 25, 2009 at 12:26 AM, Lee Trager <lt73@cs.drexel.edu> =
wrote:
>> > > Mitch, I haven't seen any problems using BTRFS and my patch on 2=
=2E6.28 or
>> > > 2.6.27, what are you doing to cause this error? Are you using th=
e 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-portin=
g 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:86=
0
>> > >> clean_tree_block+0xa4/0xb0 [btrfs]()
>> > >> [80577.151172] Modules linked in: btrfs snd_pcm_oss snd_mixer_o=
ss
>> > >> snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_de=
vice
>> > >> ipv6 ppdev snd_intel8x0 snd_ac97_codec parport_pc nvidia(P) ac9=
7_bus
>> > >> snd_pcm snd_timer ohci_hcd ssb shpchp pci_hotplug pcmcia i2c_nf=
orce2
>> > >> snd forcedeth sr_mod pcspkr parport i2c_core snd_page_alloc nvi=
dia_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 [b=
trfs]
>> > >> [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 [btr=
fs]
>> > >> [80577.151300] ?[<f8bed212>] generic_bin_search+0x162/0x1c0 [bt=
rfs]
>> > >> [80577.151315] ?[<f8bf00e6>] btrfs_cow_block+0x156/0x200 [btrfs=
]
>> > >> [80577.151330] ?[<f8bf3267>] btrfs_search_slot+0x1a7/0x910 [btr=
fs]
>> > >> [80577.151333] ?[<c01230e7>] irq_exit+0x27/0x60
>> > >> [80577.151336] ?[<c01052cb>] do_IRQ+0x6b/0x80
>> > >> [80577.151354] ?[<f8c24a55>] read_extent_buffer+0xd5/0x170 [btr=
fs]
>> > >> [80577.151369] ?[<f8bf3f7d>] btrfs_insert_empty_items+0x6d/0x41=
0 [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.o=
rg.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 e=
nd 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 ran=
ge. This
>> > >>> makes logcheck an unhappy bunny...
>> > >>>
>> > >>> ? I don't know if this behaviour is expected, and everyone usi=
ng
>> > >>> btrfs simply puts up with it for now, or if it's something unu=
sual
>> > >>> 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:81=
5 clean_tree_block+0x9d/0xbb [btrfs]()
>> > >>> Feb 23 21:45:42 vlad kernel: Hardware name: System Product Nam=
e
>> > >>> Feb 23 21:45:42 vlad kernel: Modules linked in: tun ext3 jbd b=
trfs zlib_deflate tcp_diag inet_diag kqemu cpufreq_userspace ipv6 nfsd =
nfs lockd nfs_acl auth_rpcgss sunrpc af_packet bridge stp llc xfs expor=
tfs 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_storag=
e 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_slowpat=
h+0xd8/0x111
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffff80312f11>] radix_tree_i=
nsert+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_crea=
te_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_b=
lock+0x9d/0xbb [btrfs]
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03d5eaf>] btrfs_init_n=
ew_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_bl=
ock+0x1e7/0x1f6 [btrfs]
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffff80251d9e>] __alloc_page=
s_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_allo=
c_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_curre=
nt_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_bl=
ock+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_tim=
eout+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_w=
ake_function+0x0/0x2e
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03e4809>] join_transac=
tion+0x129/0x147 [btrfs]
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffffa03c8788>] btrfs_sync_f=
s+0x70/0x78 [btrfs]
>> > >>> Feb 23 21:45:42 vlad kernel: [<ffffffff8026f332>] sync_filesys=
tems+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 ]=
---
>> > >>>
>> > >>>
>
> --
> =3D=3D=3D Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.=
org.uk =3D=3D=3D
> =A0PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org=
=2Euk
> =A0 =A0 =A0--- UNIX: British manufacturer of modular shelving units. =
---
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJpW5DIKyzvlFcI40RAi7mAJwIdyU8ZhgEyDV3Djjh0v2HUNadOACfYC1S
> 9rWCtVLER/UfOKGGMGTl/yo=3D
> =3Dd/S6
> -----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

Re: btrfs: warn_slowpath in clean_tree_block and others

[Chris Mason]

On Tue, 2009-02-24 at 23:02 +0000, Hugo Mills wrote:
> This is essentially a repost of a mail I made last week, to which I
> didn't get a reply.
> 

Sorry I missed replying to this one last week, thanks for resending.

>    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.
> 

The warnings look like i386, exactly what hardware is this?  Is your
kernel compiled for SMP or UP?

The warning you're getting is that clean_tree_block expects this block
to be locked, and giving out a warning because it is showing up as
unlocked.

So, hopefully you're on a UP kernel and my test for a locked spinlock is
broken in that config.

-chris

Re: btrfs: warn_slowpath in clean_tree_block and others

[Hugo Mills]

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

On Wed, Feb 25, 2009 at 01:36:26PM -0500, Chris Mason wrote:
> On Tue, 2009-02-24 at 23:02 +0000, Hugo Mills wrote:
> > This is essentially a repost of a mail I made last week, to which I
> > didn't get a reply.
> 
> Sorry I missed replying to this one last week, thanks for resending.

   Not a problem. I know things go astray sometimes.

> >    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.
> > 
> 
> The warnings look like i386, exactly what hardware is this?  Is your
> kernel compiled for SMP or UP?

   amd64 and a UP kernel:

hrm@vlad:linux-2.6 $ uname -a
Linux vlad 2.6.29-rc6 #1 Mon Feb 23 19:53:22 GMT 2009 x86_64 GNU/Linux

   Hardware is an original-series Turion 64 (i.e. one core) in a
Socket 745 desktop motherboard. The btrfs filesystem is in
LVM-on-RAID1 in an eSATA port-multiplier storage rack.

> The warning you're getting is that clean_tree_block expects this block
> to be locked, and giving out a warning because it is showing up as
> unlocked.
> 
> So, hopefully you're on a UP kernel and my test for a locked spinlock is
> broken in that config.

   OK. I can try patches if necessary.

   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
      --- UNIX: British manufacturer of modular shelving units. ---      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: btrfs: warn_slowpath in clean_tree_block and others

[Chris Mason]

[ resend with the list cc'd ]

On Wed, 2009-02-25 at 12:50 -0600, Mitch Harder (aka DontPanic) wrote:
> I'll try to test that out.
> 
> I had just noticed that some of my kernel configuration settings (not
> sure which ones) seem to affect the clean_tree_block warnings I've
> been getting, and one of my customizations is usually to configure the
> kernel for a single processor.
> 

I'll push out a patch tonight that fixes things, the code to test for a
locked buffer is just broken on UP.  For now, the patch below will do:

diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
index 85506c4..4513ecf 100644
--- a/fs/btrfs/locking.c
+++ b/fs/btrfs/locking.c
@@ -222,6 +222,5 @@ int btrfs_tree_unlock(struct extent_buffer *eb)
 
 int btrfs_tree_locked(struct extent_buffer *eb)
 {
-	return test_bit(EXTENT_BUFFER_BLOCKING, &eb->bflags) ||
-			spin_is_locked(&eb->lock);
+	return 1;
 }

Re: btrfs: warn_slowpath in clean_tree_block and others

[Hugo Mills]

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

On Wed, Feb 25, 2009 at 02:26:43PM -0500, Chris Mason wrote:
> [ resend with the list cc'd ]
> 
> On Wed, 2009-02-25 at 12:50 -0600, Mitch Harder (aka DontPanic) wrote:
> > I'll try to test that out.
> > 
> > I had just noticed that some of my kernel configuration settings (not
> > sure which ones) seem to affect the clean_tree_block warnings I've
> > been getting, and one of my customizations is usually to configure the
> > kernel for a single processor.
> > 
> 
> I'll push out a patch tonight that fixes things, the code to test for a
> locked buffer is just broken on UP.  For now, the patch below will do:

   Yup, that shuts it up quite effectively. :)

   Thanks,
   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
      --- If it's December 1941 in Casablanca,  what time is it ---      
                              in New York?                               

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]