| Message ID | 20130430175351.GF2580@localhost.localdomain (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello Josef On Tue, Apr 30, 2013 at 7:53 PM, Josef Bacik <jbacik@fusionio.com> wrote: > Can you run this patch and capture the output when you get the warning? You > should see some mesages before the -- [ cut here ] -- part, make sure to capture > those. Thanks, Sure. There you go (also on http://pastebin.com/7MHmgpPU): num_pages is 10000, blockgroup? yes block group offset=83999326208, size=167959920640 ------------[ cut here ]------------ WARNING: at fs/btrfs/free-space-cache.c:925 __btrfs_write_out_cache+0x9e2/0xa10 [btrfs]() Hardware name: HP Compaq dc5800 Microtower Modules linked in: arc4 md4 parport_pc ppdev rfcomm bnep bluetooth nls_utf8 cifs fscache ext2 tpm_infineon snd_hda_codec_analog coretemp kvm_intel kvm hp_wmi sparse_keymap gpio_ich snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc dm_multipath snd_seq_midi scsi_dh tpm_tis wmi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer nvidia(POF) mac_hid snd psmouse microcode serio_raw lpc_ich mei soundcore lp parport btrfs zlib_deflate libcrc32c hid_generic usbhid hid floppy e1000e usb_storage Pid: 2803, comm: sync Tainted: PF O 3.8.0-19-lowlatency #13 Call Trace: [<ffffffff8105a8df>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8105a93a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0103f52>] __btrfs_write_out_cache+0x9e2/0xa10 [btrfs] [<ffffffff81094065>] ? cpuacct_charge+0x75/0x80 [<ffffffff810145d1>] ? __switch_to+0x181/0x4d0 [<ffffffffa0104015>] btrfs_write_out_cache+0x95/0xf0 [btrfs] [<ffffffffa00b8c07>] btrfs_write_dirty_block_groups+0x527/0x620 [btrfs] [<ffffffffa012adc2>] commit_cowonly_roots+0x15a/0x22c [btrfs] [<ffffffffa00c84ec>] btrfs_commit_transaction+0x62c/0xb00 [btrfs] [<ffffffff81080070>] ? finish_wait+0x80/0x80 [<ffffffff811ca3a0>] ? fdatawait_one_bdev+0x20/0x20 [<ffffffffa009a9f2>] btrfs_sync_fs+0x62/0x110 [btrfs] [<ffffffff811ca3c0>] sync_fs_one_sb+0x20/0x30 [<ffffffff8119db59>] iterate_supers+0xe9/0xf0 [<ffffffff811ca555>] sys_sync+0x55/0x90 [<ffffffff816dfe9d>] system_call_fastpath+0x1a/0x1f ---[ end trace 88dd9bc54a43ce1a ]--- I don't think it has to do with how much data I write at that time. I also get this error, when I copy a 6kb file and then invoke "sync" to force a write. But… Hm… No, I think it IS size related. As I said, I get this error even with a file which is 6520 bytes "big". BUT I do NOT get this error when I copy a file which is just 1129 bytes "small". Some more tests - I start to get these errors with filesizes > 3916 bytes. Filesizes <= 3916 bytes -> no error. Does that make sense to you? Alexander -- => Google+ => http://plus.skwar.me <== => Chat (Jabber/Google Talk) => a.skwar@gmail.com <== -- 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
On Wed, May 01, 2013 at 12:39:47AM -0600, Alexander Skwar wrote: > Hello Josef > > On Tue, Apr 30, 2013 at 7:53 PM, Josef Bacik <jbacik@fusionio.com> wrote: > > > Can you run this patch and capture the output when you get the warning? You > > should see some mesages before the -- [ cut here ] -- part, make sure to capture > > those. Thanks, > > Sure. > > There you go (also on http://pastebin.com/7MHmgpPU): > > num_pages is 10000, blockgroup? yes > block group offset=83999326208, size=167959920640 Ok well that's not good, I'm not sure how you got a 156 gigabyte block group, but thats why that warning is going off. Can you pull btrfs-image down from here git://github.com/josefbacik/btrfs-progs.git and build that and then run ./btrfs-image -c 9 -t 4 /dev/whatever somefile.img and upload the image somewhere so I can take a look at it. Thanks, Josef -- 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
Josef Bacik <jbacik <at> fusionio.com> writes: .. > Ok well that's not good, I'm not sure how you got a 156 gigabyte block group, > but thats why that warning is going off. Can you pull btrfs-image down from > here > > git://github.com/josefbacik/btrfs-progs.git What is the difference between this git repo and the one at git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git I notice that the former has commits the latter doesn't. Is the latter the analogue to btrfs-next ? -- 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
Hello Josef On Wed, May 1, 2013 at 8:57 PM, Josef Bacik <jbacik@fusionio.com> wrote: > and build that and then run > > ./btrfs-image -c 9 -t 4 /dev/whatever somefile.img > > and upload the image somewhere so I can take a look at it. Thanks, Sure thing ;) You can download it from my Copy share: https://copy.com/6UUFqWdalibY I gpg encrypted it symmetrically; I'll send you the password in private mail. Alexander -- => Google+ => http://plus.skwar.me <== => Chat (Jabber/Google Talk) => a.skwar@gmail.com <== -- 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
On Wed, May 08, 2013 at 11:34:40AM -0600, Alexander Skwar wrote: > Hello Josef > > Did you have a chance to look at that image? Did you find anything? > > Or should I simply create a new filesystem and forget about the issue? > I haven't looked at it yet, let me run it right now and see if it's something I can fix quickly. Thanks, Josef -- 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
On Wed, May 08, 2013 at 11:34:40AM -0600, Alexander Skwar wrote: > Hello Josef > > Did you have a chance to look at that image? Did you find anything? > > Or should I simply create a new filesystem and forget about the issue? > So the file system isn't corrupt, you just got a giant block group for some reason. I've sent a patch to remove the WARN_ON() so that won't bother you anymore. You should probably rebalance to try and trim that block group down to a reasonable size, but other than that your fs is a-ok. Thanks, Josef -- 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
Hello Josef On Wed, May 8, 2013 at 10:47 PM, Josef Bacik <jbacik@fusionio.com> wrote: > On Wed, May 08, 2013 at 11:34:40AM -0600, Alexander Skwar wrote: >> Hello Josef >> >> Did you have a chance to look at that image? Did you find anything? >> >> Or should I simply create a new filesystem and forget about the issue? >> > > So the file system isn't corrupt, you just got a giant block group for some > reason. Hmm... Sure? I did start a "btrfs balance" and it consistently fails. See my dmesg output at http://pastebin.com/7XgAhZ1s At first, there are a few WARNING messages: [ 300.422702] WARNING: at /build/buildd/linux-3.8.0/fs/btrfs/delayed-ref.c:454 update_existing_ref+0x119/0x150 [btrfs]() [ 300.422960] WARNING: at /build/buildd/linux-3.8.0/fs/btrfs/delayed-ref.c:454 update_existing_ref+0x119/0x150 [btrfs]() … But there's also an error: [ 300.425633] BTRFS error (device dm-5) in __btrfs_inc_extent_ref:1935: Object already exists [ 300.425634] btrfs is forced readonly What can I do? Other than destroying that filesystem? Regards, Alexander
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index ecca6c7..2e8e098 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -921,6 +921,10 @@ static int __btrfs_write_out_cache(struct btrfs_root *root, struct inode *inode, /* Make sure we can fit our crcs into the first page */ if (io_ctl.check_crcs && (io_ctl.num_pages * sizeof(u32)) >= PAGE_CACHE_SIZE) { + printk(KERN_ERR "num_pages is %d, blockgroup? %s\n", + io_ctl.num_pages, block_group ? "yes" : "no"); + if (block_group) + printk(KERN_ERR "block group offset=%Lu, size=%Lu\n", block_group->key.objectid, block_group->key.offset); WARN_ON(1); goto out_nospc; }