Re: [PATCH] Improve error stats message
El miércoles, 7 de marzo de 2018 19:24:53 (CET) Hugo Mills escribió: >On multi-device filesystems, the two are not necessarily the same. Ouch. FWIW, I was moved to do this because I saw this conversation on IRC which made me think that people aren't understanding what the message means: hi! I noticed bdev rd 13 as a kernel message what does it mean Well, that's not the whole message. Can you paste the whole line in here? (Just one line) [3.404959] BTRFS info (device sda4): bdev /dev/sda4 errs: wr 0, rd 13, flush 0, corrupt 0, gen 0 Maybe something like this would be better: BTRFS info (device sda4): disk /dev/sda4 errors: write 0, read 13, flush 0, corrupt 0, generation 0 --- fs/btrfs/volumes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 2ceb924ca0d6..cfa029468585 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7239,7 +7239,7 @@ static void btrfs_dev_stat_print_on_error(struct btrfs_device *dev) if (!dev->dev_stats_valid) return; btrfs_err_rl_in_rcu(dev->fs_info, - "bdev %s errs: wr %u, rd %u, flush %u, corrupt %u, gen %u", + "disk %s errors: write %u, read %u, flush %u, corrupt %u, generation %u", rcu_str_deref(dev->name), btrfs_dev_stat_read(dev, BTRFS_DEV_STAT_WRITE_ERRS), btrfs_dev_stat_read(dev, BTRFS_DEV_STAT_READ_ERRS), -- 2.16.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Improve error stats message
A typical notification of filesystem errors looks like this:
BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 1, flush 0, corrupt 0,
gen 0
The device name is being printed twice. Also, these abbreviatures
feel unnecesary. Make the message look like this instead:
BTRFS error (device sda2): errors: write 0, read 1, flush 0, corrupt 0,
generation 0
Signed-off-by: Diego Calleja <dieg...@gmail.com>
---
fs/btrfs/volumes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2ceb924ca0d6..52fee5bb056f 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -7238,9 +7238,8 @@ static void btrfs_dev_stat_print_on_error(struct
btrfs_device *dev)
{
if (!dev->dev_stats_valid)
return;
- btrfs_err_rl_in_rcu(dev->fs_info,
- "bdev %s errs: wr %u, rd %u, flush %u, corrupt %u, gen %u",
- rcu_str_deref(dev->name),
+ btrfs_err_rl(dev->fs_info,
+ "errors: write %u, read %u, flush %u, corrupt %u, generation
%u",
btrfs_dev_stat_read(dev, BTRFS_DEV_STAT_WRITE_ERRS),
btrfs_dev_stat_read(dev, BTRFS_DEV_STAT_READ_ERRS),
btrfs_dev_stat_read(dev, BTRFS_DEV_STAT_FLUSH_ERRS),
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] Btrfs: heuristic add detection of zeroed sample
El miércoles, 23 de agosto de 2017 2:26:48 (CEST) Timofey Titovets escribió:
> + for (i = 0; i < workspace->sample_size; i += sizeof(zero)) {
> + if (memcmp(>sample[i], , sizeof(zero)))
> + return false;
Instead of just checking for 0, wouldn't it be a better idea to check
for any kind of repetitions?
As in, iterate over the sample and memcmp() each part of sample with
the previous one. The cost would be the same, and it would detect not
just zeros, but any kind of repeated data. Is there any reason I'm
missing for not doing this?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: KASAN: use-after-free in btrfs_map_bio
In the latest git, with KASAN enabled: [ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at addr 8803801a76fc [ 180.560151] Read of size 4 by task localStorage DB/924 [ 180.560160] CPU: 0 PID: 924 Comm: localStorage DB Not tainted 4.11.0-rc6-g39da7c509acf #19 [ 180.560165] Hardware name: Shuttle Inc. SH81R/FH81, BIOS 1.04 01/26/2015 [ 180.560170] Call Trace: [ 180.560181] dump_stack+0xd5/0x144 [ 180.560190] ? _atomic_dec_and_lock+0xcc/0xcc [ 180.560205] kasan_object_err+0x21/0x90 [ 180.560212] kasan_report+0x38b/0x980 [ 180.560219] ? generic_make_request+0x990/0x990 [ 180.560225] ? btrfs_map_bio+0x994/0x10b0 [ 180.560230] ? btrfs_map_bio+0x994/0x10b0 [ 180.560239] ? btrfs_map_bio+0x994/0x10b0 [ 180.560253] __asan_report_load4_noabort+0x19/0x20 [ 180.560259] btrfs_map_bio+0x994/0x10b0 [ 180.560275] ? btrfs_rmap_block+0x1250/0x1250 [ 180.560293] ? debug_check_no_locks_freed+0x350/0x350 [ 180.560302] ? print_irqtrace_events+0x290/0x290 [ 180.560315] btrfs_submit_bio_hook+0x285/0x810 [ 180.560322] ? btrfs_merge_bio_hook+0x23a/0x4b0 [ 180.560333] ? btrfs_readpage_end_io_hook+0x560/0x560 [ 180.560341] submit_one_bio+0x217/0x400 [ 180.560352] submit_extent_page+0xcc/0x4a0 [ 180.560366] __extent_writepage_io+0x780/0xbc0 [ 180.560375] ? end_extent_writepage+0x240/0x240 [ 180.560401] __extent_writepage+0x73c/0xbb0 [ 180.560416] ? __extent_writepage_io+0xbc0/0xbc0 [ 180.560426] ? clear_page_dirty_for_io+0x3cd/0xaa0 [ 180.560435] ? redirty_page_for_writepage+0x90/0x90 [ 180.560451] extent_write_cache_pages.constprop.11+0x681/0xb80 [ 180.560460] ? btrfs_sync_file+0x842/0xe10 [ 180.560475] ? __extent_writepage+0xbb0/0xbb0 [ 180.560486] ? print_irqtrace_events+0x290/0x290 [ 180.560509] ? do_raw_spin_trylock+0x110/0x110 [ 180.560522] extent_writepages+0xe3/0x170 [ 180.560530] ? extent_write_locked_range+0x3d0/0x3d0 [ 180.560538] ? btrfs_merge_bio_hook+0x4b0/0x4b0 [ 180.560545] ? wbc_attach_and_unlock_inode+0x14e/0xb00 [ 180.560552] ? lock_acquire+0x11e/0x420 [ 180.560560] ? __writeback_single_inode+0x10c0/0x10c0 [ 180.560566] ? __clear_extent_bit+0x4ef/0xbd0 [ 180.560576] btrfs_writepages+0x49/0x80 [ 180.560584] do_writepages+0x9d/0x110 [ 180.560595] __filemap_fdatawrite_range+0x25d/0x3a0 [ 180.560603] ? replace_page_cache_page+0x3d0/0x3d0 [ 180.560617] ? clear_state_bit+0x840/0x840 [ 180.560626] ? up_write+0x73/0x100 [ 180.560637] filemap_fdatawrite_range+0x13/0x20 [ 180.560644] btrfs_fdatawrite_range+0x54/0x130 [ 180.560653] __btrfs_write_out_cache+0xb56/0xf10 [ 180.560669] ? write_pinned_extent_entries+0x450/0x450 [ 180.560679] ? debug_lockdep_rcu_enabled+0x7b/0x90 [ 180.560686] ? do_raw_spin_trylock+0x110/0x110 [ 180.560693] ? do_raw_spin_trylock+0x110/0x110 [ 180.560709] ? _raw_spin_unlock+0x27/0x40 [ 180.560716] ? lookup_free_space_inode+0x6d/0x300 [ 180.560727] btrfs_write_out_cache+0x108/0x210 [ 180.560740] btrfs_start_dirty_block_groups+0x631/0xfc0 [ 180.560757] ? btrfs_force_chunk_alloc+0x40/0x40 [ 180.560765] ? mutex_trylock+0x210/0x210 [ 180.560771] ? btrfs_run_delayed_refs+0x484/0x710 [ 180.560787] btrfs_commit_transaction+0x33f/0x2420 [ 180.560795] ? trace_hardirqs_on_caller+0x46c/0x6b0 [ 180.560803] ? trace_hardirqs_on+0xd/0x10 [ 180.560810] ? _raw_spin_unlock_irq+0x2c/0x50 [ 180.560818] ? btrfs_lookup_first_ordered_extent+0x148/0x2e0 [ 180.560827] ? btrfs_apply_pending_changes+0x150/0x150 [ 180.560834] ? btrfs_have_ordered_extents_in_range+0x30/0x30 [ 180.560849] ? btrfs_wait_ordered_range+0xae/0x210 [ 180.560860] btrfs_sync_file+0x842/0xe10 [ 180.560873] ? start_ordered_ops+0x30/0x30 [ 180.560880] ? __fget+0x50/0x4a0 [ 180.560896] ? __fget+0x23c/0x4a0 [ 180.560906] ? start_ordered_ops+0x30/0x30 [ 180.560914] vfs_fsync_range+0xe8/0x3d0 [ 180.560920] ? __fget_light+0x9a/0x250 [ 180.560927] ? trace_hardirqs_on_caller+0x46c/0x6b0 [ 180.560938] do_fsync+0x3d/0x70 [ 180.560948] SyS_fdatasync+0x13/0x20 [ 180.560955] entry_SYSCALL_64_fastpath+0x1f/0xc2 [ 180.560961] RIP: 0033:0x7f2e79004a4d [ 180.560967] RSP: 002b:7f2e549a0760 EFLAGS: 0293 ORIG_RAX: 004b [ 180.560976] RAX: ffda RBX: 7f2e42c89710 RCX: 7f2e79004a4d [ 180.560982] RDX: 00c9 RSI: 0008 RDI: 00c9 [ 180.560987] RBP: 0046 R08: R09: [ 180.560992] R10: R11: 0293 R12: [ 180.560997] R13: 7f2e58bf7000 R14: R15: 0001 [ 180.561016] Object at 8803801a7680, in cache bio-2 size: 304 [ 180.561021] Allocated: [ 180.561025] PID = 924 [ 180.561034] save_stack_trace+0x1b/0x20 [ 180.561040] kasan_kmalloc+0xee/0x190 [ 180.561046] kasan_slab_alloc+0x12/0x20 [ 180.561054] kmem_cache_alloc+0x108/0x4a0 [ 180.561061] mempool_alloc_slab+0x15/0x20 [ 180.561066]
Re: Input/output error, nothing appended in dmesg
El sábado, 6 de agosto de 2016 0:45:13 (CEST) Tomasz Chmielewski escribió: > And, miracle cure O_o > > # file ./2016-08-02/serverX/syslog.log > ERROR: cannot read `./2016-08-02/serverX/syslog.log' (Input/output > error) > > # echo 3 > /proc/sys/vm/drop_caches > > # file 2016-08-02/serverX/syslog.log > 2016-08-02/serverX/syslog.log: ASCII text, with very long lines FWIW, bugs similar to this one were reported in the past: http://www.spinics.net/lists/linux-btrfs/msg54962.html http://www.spinics.net/lists/linux-btrfs/msg52371.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs stability
Hi there, I've been using btrfs with a raid5 configuration with 3 disks for 6 months, and then with 4 disks for a couple of months more. I run a weekly scrub, and a monthly balance. Btrfs is the only fs that can add drives one by one to an existing raid setup, and use the new space inmediately, without replacing all the drives. For me, this is one of the strongest points. And, as far as I understand, If I keep and eye on the free space available, and no drives fail, the filesystem would last indefinitely. However, the code to replace a failed/missing drive is not yet final, as I have discovered reading some wikis and this mailing list. Maybe I'm wrong. I haven't been able to find a timeline/roadmap about when the replace command will be stable/ready for use. Is this someone's priority? Is it planned for the next one,two or three years coming? Thanks in advance. -- -- Use of a keyboard or mouse may be linked to serious injuries or disorders. diego dot torres at gmail dot com - Madrid / Spain -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Input/output error on newly created file
El jueves, 12 de mayo de 2016 8:46:00 (CEST) Nikolaus Rath escribió: > *ping* > > Anyone any idea? All I can say is that I've had the same problem in the past. In my case, the problematic files where active torrents. The interesting thing is that I was able to read them correctly up to a point, then I would get the same error as you. No messages in dmesg. The amount of data I was able to read from them was not random, it was something multiple of 4K. After reboot the problems went away and I wasn't able to reproduce it. There has been reports of similiar issues in the past: http://www.spinics.net/lists/linux-btrfs/msg52371.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Reproducible corruption issue in stable, with possible patch unmerged?
[repost, since the previous mail was rejected by vger.kernel.org] I got these messages in my dmesg: [ 2587.841376] BTRFS error (device sdc1): partial page write in btrfs with offset 0 and length 8392704 [ 2588.814182] BTRFS critical (device sdc1): bad ordered accounting left 0 size 4096 With no other errors before. After rebooting I got btrfs errors and widespreading filesystem corruption (pool of three disks created with -d raid0 and -m raid1) I reinstalled the system (current arch linux installer, which runs 4.2) and started to restore the backup. Surprisingly, I got exactly the same errors again. I reinstalled again, and after rebooting to the new system, running 4.2.5, I tried to restore the backup and got the same messages and corruption again. Then I tried reinstalling with the 4.1.12 LTS version, and it all worked fine. Now, the interesting thing is that, after googling this error, I didn't found any interesting references except a patch sent to this mailing list which seems to fix a problem that causes the same error output. The patch doesn't seem to have been merged: http://lkml.iu.edu/hypermail/linux/kernel/1412.1/03297.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Help with btrfs filesystem problems
] ? check_pending_worker_creates+0xe0/0xe0 [btrfs] Apr 22 11:18:38 ysmha01 kernel: [810821ce] kthread+0xce/0xe0 Apr 22 11:18:38 ysmha01 kernel: [81082100] ? kthread_freezable_should_stop+0x70/0x70 Apr 22 11:18:38 ysmha01 kernel: [815f9448] ret_from_fork+0x58/0x90 Apr 22 11:18:38 ysmha01 kernel: [81082100] ? kthread_freezable_should_stop+0x70/0x70 Apr 22 11:18:38 ysmha01 kernel: Code: 10 21 62 a0 e8 f0 00 fc ff c7 85 38 ff ff ff 01 00 00 00 e9 dc fa ff ff 0f 0b eb fe 0f 0b eb fe 0f 0b 0f 1f 80 00 00 00 00 eb f7 0f 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 0f 0b eb fe 0f Apr 22 11:18:38 ysmha01 kernel: RIP [a05c3de2] __btrfs_drop_extents+0xb52/0xb90 [btrfs] Apr 22 11:18:38 ysmha01 kernel: RSP 8807d8037b38 Apr 22 11:18:38 ysmha01 kernel: ---[ end trace e7607252d1383d86 ]--- At this point, the machine was rebooted and upon mount, I also used the clear_cache mount option, later the machine crashed again. Apr 22 13:41:19 ysmha01 kernel: block drbd0: role( Secondary - Primary ) Apr 22 13:42:08 ysmha01 kernel: device fsid 7a38f3ab-f3b0-4b3d-81c0-28b347b26da1 devid 1 transid 1699374 /dev/drbd0 Apr 22 13:42:08 ysmha01 kernel: btrfs: force clearing of disk cache Apr 22 13:42:08 ysmha01 kernel: btrfs: disk space caching is enabled Apr 22 13:42:45 ysmha01 kernel: SELinux: initialized (dev drbd0, type btrfs), uses xattr Apr 22 13:47:39 ysmha01 kernel: INFO: task btrfs-transacti:3175 blocked for more than 120 seconds. Apr 22 13:47:39 ysmha01 kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Apr 22 13:47:39 ysmha01 kernel: btrfs-transacti D 81810d00 0 3175 2 0x0080 Apr 22 13:47:39 ysmha01 kernel: 880303301ce8 0046 880303301fd8 0001314 Apr 22 13:47:39 ysmha01 kernel: 880303300010 00013140 00013140 00013140 Apr 22 13:47:39 ysmha01 kernel: 880303301fd8 00013140 88046988a340 88046bb69360 Apr 22 13:47:39 ysmha01 kernel: Call Trace: Apr 22 13:47:39 ysmha01 kernel: [815eeed9] schedule+0x29/0x70 Apr 22 13:47:39 ysmha01 kernel: [815ed085] schedule_timeout+0x195/0x220 Apr 22 13:47:39 ysmha01 kernel: [81082c90] ? prepare_to_wait+0x60/0x90 Apr 22 13:47:39 ysmha01 kernel: [a05b0457] btrfs_commit_transaction+0x1f7/0xa40 [btrfs] Apr 22 13:47:39 ysmha01 kernel: [a05b111b] ? start_transaction+0xab/0x4d0 [btrfs] Apr 22 13:47:39 ysmha01 kernel: [810829e0] ? wake_up_bit+0x40/0x40 Apr 22 13:47:39 ysmha01 kernel: [a05aac96] transaction_kthread+0x1a6/0x220 [btrfs] Apr 22 13:47:39 ysmha01 kernel: [a05aaaf0] ? btree_readpage_end_io_hook+0x2c0/0x2c0 [btrfs] Apr 22 13:47:39 ysmha01 kernel: [a05aaaf0] ? btree_readpage_end_io_hook+0x2c0/0x2c0 [btrfs] Apr 22 13:47:39 ysmha01 kernel: [810821ce] kthread+0xce/0xe0 Apr 22 13:47:39 ysmha01 kernel: [81082100] ? kthread_freezable_should_stop+0x70/0x70 Apr 22 13:47:39 ysmha01 kernel: [815f9448] ret_from_fork+0x58/0x90 Apr 22 13:47:39 ysmha01 kernel: [81082100] ? kthread_freezable_should_stop+0x70/0x70 Apr 22 13:49:39 ysmha01 kernel: INFO: task btrfs-transacti:3175 blocked for more than 120 seconds. Apr 22 13:49:39 ysmha01 kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Apr 22 13:49:39 ysmha01 kernel: btrfs-transacti D 81810d00 0 3175 2 0x0080 Apr 22 13:49:39 ysmha01 kernel: 880303301ce8 0046 880303301fd8 00013140 Apr 22 13:49:39 ysmha01 kernel: 880303300010 00013140 00013140 00013140 Apr 22 13:49:39 ysmha01 kernel: 880303301fd8 00013140 88046988a340 88046bb69360 snip.. When the oops happens, then the mount point becomes unusable. What would be the best path to recovery from here? What other information may I provide? Diego -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] [RFC] RAID-level terminology change
El Domingo, 10 de marzo de 2013 12:23:56 Martin Steigerwald escribió: Any other idea to make it less cryptic? I would vote for optionally allowing to expand the codes into something more verbose and self-documented, ie: 1CmS1P - 1Copy-manyStripes-1Parity -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs progs: quota groups support
On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió: From: Arne Jansen sensi...@gmx.net Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net Signed-off-by: Arne Jansen sensi...@gmx.net --- This is the rebased version of Arne's qgroup patch set. He's the original author, which is why I'm sending with his author tag. A small suggestion, it would be nice to have a man page update. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [systemd-devel] systemd-udevd: excessive I/O usage
[resend, for some reason kmail formatted the previous message with html] On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió: Result: boot from ext4 takes less than 15 seconds, while boot from btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data file is not valid anyway on btrfs). I also had this problem. It turns out that btrfs was creating the space cache from scratch (which takes several minutes) on each boot, for some reason. I added the space_cache mount option to fstab, and now my system boots fast. I suggest trying it. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Honest timeline for btrfsck
On Viernes, 7 de Octubre de 2011 21:10:33 Asdo escribió: failures, but you can always mount by rolling back to a previous uberblock, showing an earlier view of the filesystem, which would be consistent. This is already available in Btrfs, command btrfsck -s. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] btrfs: fix memory leak in btrfs_defrag_file
kmemleak found this:
unreferenced object 0x8801b64af968 (size 512):
comm btrfs-cleaner, pid 3317, jiffies 4306810886 (age 903.272s)
hex dump (first 32 bytes):
00 82 01 07 00 ea ff ff c0 83 01 07 00 ea ff ff
80 82 01 07 00 ea ff ff c0 87 01 07 00 ea ff ff
backtrace:
[816875cc] kmemleak_alloc+0x5c/0xc0
[8114aec3] kmem_cache_alloc_trace+0x163/0x240
[8127a290] btrfs_defrag_file+0xf0/0xb20
[8125d9a5] btrfs_run_defrag_inodes+0x165/0x210
[812479d7] cleaner_kthread+0x177/0x190
[81075c7d] kthread+0x8d/0xa0
[816af5f4] kernel_thread_helper+0x4/0x10
[] 0x
pages is not always freed. Fix it removing the unnecesary additional return.
Signed-off-by: Diego Calleja dieg...@gmail.com
---
fs/btrfs/ioctl.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux/fs/btrfs/ioctl.c
===
--- linux.orig/fs/btrfs/ioctl.c
+++ linux/fs/btrfs/ioctl.c
@@ -1130,17 +1130,15 @@ int btrfs_defrag_file(struct inode *inod
disk_super = root-fs_info-super_copy;
features = btrfs_super_incompat_flags(disk_super);
if (range-compress_type == BTRFS_COMPRESS_LZO) {
features |= BTRFS_FEATURE_INCOMPAT_COMPRESS_LZO;
btrfs_set_super_incompat_flags(disk_super, features);
}
- if (!file)
- kfree(ra);
- return defrag_count;
+ ret = defrag_count;
out_ra:
if (!file)
kfree(ra);
kfree(pages);
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING in -rc3-00023-g14c62e7
On Sábado, 27 de Agosto de 2011 00:33:51 Diego Calleja escribió: On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió: Do you have autodefrag enabled? Yes It seems that this problem has already been solved by Konstantin Khlebnikov, he posted a patch on 17 August [PATCH] btrfs: fix warning in iput for bad-inode -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING in -rc3-00023-g14c62e7
On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió: Do you have autodefrag enabled? Yes -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING in -rc3-00023-g14c62e7
This is what I got in my dmesg...I have lots of these warnings, didn't notice it until now. [ 235.705766] [ cut here ] [ 235.705772] WARNING: at fs/inode.c:1309 iput+0x1ed/0x210() [ 235.705773] Hardware name: [ 235.705774] Modules linked in: ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_hdmi snd_hda_codec_realtek wacom snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore e1000e i2c_i801 snd_page_alloc virtio_net virtio virtio_ring kvm_intel kvm [last unloaded: scsi_wait_scan] [ 235.705788] Pid: 3203, comm: btrfs-cleaner Not tainted 3.1.0-rc3-00023-g14c62e7 #4 [ 235.705789] Call Trace: [ 235.705794] [8104bbcf] warn_slowpath_common+0x7f/0xc0 [ 235.705796] [8104bc2a] warn_slowpath_null+0x1a/0x20 [ 235.705797] [8116922d] iput+0x1ed/0x210 [ 235.705800] [8123b3ac] btrfs_iget+0x1cc/0x460 [ 235.705804] [815dbc56] ? _raw_spin_unlock+0x16/0x40 [ 235.705807] [8123f8ce] btrfs_run_defrag_inodes+0x12e/0x210 [ 235.705809] [8122a09b] cleaner_kthread+0x18b/0x1a0 [ 235.705811] [815dbe0a] ? _raw_spin_unlock_irqrestore+0x2a/0x60 [ 235.705813] [81229f10] ? transaction_kthread+0x290/0x290 [ 235.705815] [8106e42c] kthread+0x8c/0xa0 [ 235.705818] [815e51f4] kernel_thread_helper+0x4/0x10 [ 235.705820] [81037cde] ? finish_task_switch+0x4e/0xe0 [ 235.705822] [815dbc9c] ? _raw_spin_unlock_irq+0x1c/0x40 [ 235.705824] [815dc64e] ? retint_restore_args+0xe/0xe [ 235.705826] [8106e3a0] ? kthread_worker_fn+0x190/0x190 [ 235.705828] [815e51f0] ? gs_change+0xb/0xb [ 235.705829] ---[ end trace 522a9ae26c065662 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: version (was: btrfs, broken design?)
On Miércoles, 26 de Enero de 2011 11:13:20 Erik Logtenberg escribió: Diego, pls don't read anything negative in my comments, I enjoy and respect your work very much! If you could find time to add those latest changes to the wiki, it would be greatly appreciated. Thanks for your suggestion, I've updated the Changelog and removed the old items from the news section. 2.6.36 didn't had many btrfs changes, there was no new features. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
On Lunes, 16 de Agosto de 2010 17:45:29 Chris Ball escribió: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. But doesn't this happen only with cheap disks that don't honour barriers correctly? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] Btrfs: compressed file size ioctl
On Viernes, 6 de Agosto de 2010 14:21:44 Ulrich Hecht escribió: ioctl(d, BTRFS_IOC_COMPR_SIZE, size); I wonder...it's not possible to fit this into FIEMAP somehow? I though that FIEMAP has been designed with compressed data in mind. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Poor performance with qemu
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the raw qemu format according to virt-manager and, of course, placed on a btrfs filesystem, running the latest mainline git) is awfully slow, no matter what OS is running inside the VM. The PCBSD installer says it's copying data at a 40-50 KB/s rate. Is someone using KVM and having better numbers than me? How can I help to debug this workload? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failures
On Viernes, 26 de Febrero de 2010 20:09:15 Chris Mason escribió: My would be the super block, it is updated more often and so more likely to get stuck in the array's cache. IIRC, this is exactly the same problem that ZFS users have been hitting. Some users got cheap disks that don't honour barriers correctly, so their uberblock didn't have the correct data. They developed an app that tries to rollback transactions to get the pool into a sane state...I guess that fsck will be able to do that at some point? Stupid question from someone who is not a fs dev...it's not possible to solve this issue by doing some sort of superblock journaling? Since there are several superblock copies you could: -Modify a secondary superblock copy to point to the tree root block that still has not been written to disk -Write whatever tree root block has been COW'ed -Modify the primary superblock So in case of these failures, mount code could look in the secondary superblock copy before failing. Since barriers are not being honoured, there's still a possibility that the tree root blocks would be written before the secondary superblock block that was submitted before, but that problem would be much harder to hit I guess. But maybe the fs code can not know where the tree root blocks are going to be written before writting them, and hence it can't generate a valid superblock? Sorry if all this has not sense at all, I'm just wondering if there's a way to solve these drive issues without any kind of recovery tools -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper error handling on NULL pointers
On Jueves 22 Octubre 2009 12:15:59 Andi Drebes escribió: I'd really appreciate to see a TODO section somewhere in the wiki. [..] There's one (needs updating): http://btrfs.wiki.kernel.org/index.php/Development_timeline Also, http://btrfs.wiki.kernel.org/index.php/Project_ideas has some ideas. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Warning and BUG using btrfs-vol -b
On Wednesday 07 October 2009 05:17:54 Chris Mason escribió: Thanks, I'll try to reproduce. Which raid level did you use for data? If not raid1, could you try with raid1? ;) I'm not sure, since the utils won't tell. I mkfs'ed and mounted one of the 3.5GB files with no special options, and copied some files on it. I mkfs'ed the second file, put it in a loop device, and added it to the pool with btrfs-vol -a. Then I run btrfs-vol -b and I copied more files and rebalanced several times. Then I zeroed one of the files used as disks, and tried to read the files in the volume (unsucessfully). Then I rebalanced, and I hit the oops. It seems to be very reproducible. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Warning and BUG using btrfs-vol -b
On Wednesday 07 October 2009 21:45:29 Chris Mason escribió: I'm afraid this is good old enospc. Balancing still needs some work to be completely safe. I've tried using less data and raid1, but I can't reproduce it. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Warning and BUG using btrfs-vol -b
By the way, i think it'd be useful if debug-tree would tell which policy
the fs is applying to each chunk. Something like this:
item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 8379826176) itemoff 3495
itemsize 112
chunk length 319881216 owner 2 type 17 (data on RAID1)
num_stripes 2
stripe 0 devid 2 offset 2265382912
stripe 1 devid 1 offset 989003776
Index: btrfs-progs-unstable/print-tree.c
===
--- btrfs-progs-unstable.orig/print-tree.c 2009-10-07 16:44:53.013210615
+0200
+++ btrfs-progs-unstable/print-tree.c 2009-10-07 21:37:46.162546261 +0200
@@ -79,15 +79,37 @@
return 0;
}
+static void print_chunk_type(u64 chunk_flags)
+{
+ printf( type %llu (, chunk_flags);
+
+ if (chunk_flags BTRFS_BLOCK_GROUP_DATA)
+ printf(data);
+ if (chunk_flags BTRFS_BLOCK_GROUP_METADATA)
+ printf(metadata);
+ if (chunk_flags BTRFS_BLOCK_GROUP_SYSTEM)
+ printf(system??);
+ if (chunk_flags BTRFS_BLOCK_GROUP_DUP)
+ printf(dup??);
+ if (chunk_flags BTRFS_BLOCK_GROUP_RAID0)
+ printf( on RAID0);
+ if (chunk_flags BTRFS_BLOCK_GROUP_RAID1)
+ printf( on RAID1);
+ if (chunk_flags BTRFS_BLOCK_GROUP_RAID10)
+ printf( on RAID10);
+ printf() );
+}
+
static void print_chunk(struct extent_buffer *eb, struct btrfs_chunk *chunk)
{
int num_stripes = btrfs_chunk_num_stripes(eb, chunk);
int i;
- printf(\t\tchunk length %llu owner %llu type %llu num_stripes %d\n,
+ printf(\t\tchunk length %llu owner %llu,
(unsigned long long)btrfs_chunk_length(eb, chunk),
- (unsigned long long)btrfs_chunk_owner(eb, chunk),
- (unsigned long long)btrfs_chunk_type(eb, chunk),
- num_stripes);
+ (unsigned long long)btrfs_chunk_owner(eb, chunk));
+ print_chunk_type((unsigned long long)btrfs_chunk_type(eb, chunk));
+ printf(num_stripes %d\n, num_stripes);
+
for (i = 0 ; i num_stripes ; i++) {
printf(\t\t\tstripe %d devid %llu offset %llu\n, i,
(unsigned long long)btrfs_stripe_devid_nr(eb, chunk, i),
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Warning and BUG using btrfs-vol -b
I was playing with btrfs with 2 files of 3.5 GB (using loop), I completely zeroed one of the files. As expected, I had checksum failures, and I run btrfs-vol -b just to see what happened, and I got this (using -rc3): [25765.340492] btrfs csum failed ino 260 off 122880 csum 2566472073 private 3262812575 [25765.340530] btrfs csum failed ino 260 off 118784 csum 2566472073 private 1515197691 [25765.340560] btrfs csum failed ino 260 off 114688 csum 2566472073 private 1467250717 [25765.340589] btrfs csum failed ino 260 off 110592 csum 2566472073 private 551456760 [25765.340618] btrfs csum failed ino 260 off 106496 csum 2566472073 private 2751401677 [25765.340647] btrfs csum failed ino 260 off 102400 csum 2566472073 private 2648834377 [25765.340675] btrfs csum failed ino 260 off 98304 csum 2566472073 private 467965630 [25765.340703] btrfs csum failed ino 260 off 94208 csum 2566472073 private 3164409631 [25765.340732] btrfs csum failed ino 260 off 90112 csum 2566472073 private 2042500030 [25765.340760] btrfs csum failed ino 260 off 86016 csum 2566472073 private 830495785 [25809.292651] btrfs: relocating block group 3541041152 flags 9 [25809.416493] __ratelimit: 158 callbacks suppressed [25809.416498] btrfs csum failed ino 257 off 61440 csum 2566472073 private 1989812792 [25809.416537] btrfs csum failed ino 257 off 57344 csum 2566472073 private 3105762401 [25809.416603] btrfs csum failed ino 257 off 53248 csum 2566472073 private 2215503813 [25809.416719] btrfs csum failed ino 257 off 323584 csum 2566472073 private 883932373 [25809.416731] btrfs csum failed ino 257 off 49152 csum 2566472073 private 1747807236 [25809.416752] btrfs csum failed ino 257 off 319488 csum 2566472073 private 2519068844 [25809.416774] btrfs csum failed ino 257 off 45056 csum 2566472073 private 3487590687 [25809.416783] btrfs csum failed ino 257 off 315392 csum 2566472073 private 2599709027 [25809.416813] btrfs csum failed ino 257 off 311296 csum 2566472073 private 157132003 [25809.416823] btrfs csum failed ino 257 off 40960 csum 2566472073 private 599615997 [25809.657271] [ cut here ] [25809.657294] WARNING: at fs/btrfs/relocation.c:3588 btrfs_relocate_block_group+0x27f/0x390 [btrfs]() [25809.657298] Hardware name: System Product Name [25809.657300] Modules linked in: btrfs loop crc32c libcrc32c ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc kvm_intel kvm i915 snd_ca0106 snd_rawmidi drm_kms_helper cfbcopyarea snd_ac97_codec ac97_bus video snd_pcm_oss snd_mixer_oss snd_pcm backlight snd_timer cfbimgblt snd processor button cfbfillrect intel_agp wacom soundcore snd_page_alloc usbhid fan fuse ehci_hcd uhci_hcd thermal thermal_sys usbcore atl1 mii [last unloaded: btrfs] [25809.657350] Pid: 15354, comm: btrfs-vol Not tainted 2.6.32-rc3 #1 [25809.657353] Call Trace: [25809.657361] [8104f9bb] warn_slowpath_common+0x7b/0xc0 [25809.657366] [8104fa14] warn_slowpath_null+0x14/0x20 [25809.657377] [a0396b7f] btrfs_relocate_block_group+0x27f/0x390 [btrfs] [25809.657390] [a037cfab] btrfs_relocate_chunk+0x8b/0x5e0 [btrfs] [25809.657404] [a0372a0b] ? map_extent_buffer+0xdb/0xe0 [btrfs] [25809.657417] [a0371b13] ? unmap_extent_buffer+0x13/0x40 [btrfs] [25809.657431] [a0366c54] ?
[PATCH] Fix possible pointer dereference
We should always check btrfs_alloc_path(). Some places BUG(), others return -ENOMEM, btrfs_insert_dir_item() seems like it can return safely. Signed-off-by: Diego Calleja dieg...@gmail.com --- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200 +++ linux/fs/btrfs/dir-item.c 2009-10-06 19:01:00.329132291 +0200 @@ -147,6 +147,9 @@ int btrfs_insert_dir_item(struct btrfs_t key.offset = btrfs_name_hash(name, name_len); path = btrfs_alloc_path(); + if (!path) + return -ENOMEM; + path-leave_spinning = 1; data_size = sizeof(*dir_item) + name_len; -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/disk-io.c:2221!
You probably should have CC'ed the btrfs mailing list (I already did in this mail) On Sábado 01 Agosto 2009 11:50:08 Thomas Meyer escribió: kernel BUG at fs/btrfs/disk-io.c:2221! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/block/sdc/sdc1/start CPU 1 Modules linked in: btrfs olympic forcedeth rndis_wlan floppy [last unloaded: scsi_wait_scan] Pid: 23806, comm: umount Tainted: GW 2.6.31-rc4-rt1 #3 MS-7250 RIP: 0010:[a00589ad] [a00589ad] write_all_supers+0x22f/0x259 [btrfs] RSP: 0018:88009e575ce8 EFLAGS: 00010292 RAX: 003a RBX: 8801980889f8 RCX: 88009e575ba8 RDX: RSI: 0202 RDI: 5661d985 RBP: 0001 R08: 0002 R09: R10: R11: 88009e575c88 R12: 88011e0b2000 R13: R14: 880198088980 R15: 88011e094ed6 FS: 7fa0ba6ef740() GS:8800280ac000() knlGS:f49ffb70 CS: 0010 DS: ES: CR0: 8005003b CR2: 00be1858 CR3: 9204a000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process umount (pid: 23806, threadinfo 88009e574000, task 8801bbd3a760) Stack: 88009e575d10 88011e094ee6 0001 88011e094dcb 0 8801980889f8 8439bfff 8439c000 5661d985 0 852b4000 88011e0b2000 88018024f8a0 880091c92d70 Call Trace: [a005c510] ? btrfs_commit_transaction+0x5ff/0x6d7 [btrfs] [810884bd] ? autoremove_wake_function+0x0/0x55 [81166dfc] ? sync_quota_sb+0x58/0x133 [8113a1a4] ? __sync_filesystem+0x3b/0x82 [81118cd3] ? generic_shutdown_super+0x31/0x10c [81118e28] ? kill_anon_super+0x1d/0x71 [81119691] ? deactivate_super+0x63/0xa6 [81130949] ? sys_umount+0x2e4/0x32a [8102bf2b] ? system_call_fastpath+0x16/0x1b Code: 24 90 01 00 00 48 8b b8 b0 21 00 00 48 83 c7 48 e8 dd 30 7b e1 3b 6c 24 10 7e 14 89 ee 48 c7 c7 1a 39 09 a0 31 c0 e8 eb 09 7b e1 0f 0b eb fe 31 c0 48 8b 54 24 38 65 48 33 14 25 28 00 00 00 74 RIP [a00589ad] write_all_supers+0x22f/0x259 [btrfs] RSP 88009e575ce8 ---[ end trace 1e2f23bdcf389667 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Performance results on Experimental branch
On Miércoles 25 Febrero 2009 22:07:33 Steven Pratt escribió: All in all good progress. Results and graphs can be found here: http://btrfs.boxacle.net/repository/raid/history/History.html Some graphs seem to be broken...btrfs gets a transparent color. For example here: http://btrfs.boxacle.net/repository/raid/history/History_Mail_server_simulation._num_threads=16.FFSB_Ops_per_Sec.png -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Performance results on Experimental branch
On Miércoles 25 Febrero 2009 23:55:08 Steven Pratt escribió: Unless I am missing something, what you are referring to is a simple wraping/alignment issue in the key on the long name on the experimental btrfs. It is the Brown bar. Let me know if this is not the issue. doh, you're right. Sorry, it's time to sleep here ;( -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] always check btrfs_alloc_path() failure
There are some places that don't check at all btrfs_alloc_path() failures,
I added BUG_ON's for all of them, as many other codepaths that don't know
how to handle the failures seem to do.
In case of not applying this patch, I must notice that there's one real
bugfix that should be applied, it's a null pointer dereference on inode.c:
2506: path = btrfs_alloc_path();
2507: path-reada = -1;
2508: BUG_ON(!path);
Index: btrfs-unstable-standalone/dir-item.c
===
--- btrfs-unstable-standalone.orig/dir-item.c 2008-12-29 21:23:16.940588725
+0100
+++ btrfs-unstable-standalone/dir-item.c2008-12-29 21:30:13.654588510
+0100
@@ -146,6 +146,7 @@
btrfs_set_key_type(key, BTRFS_DIR_ITEM_KEY);
key.offset = btrfs_name_hash(name, name_len);
path = btrfs_alloc_path();
+ BUG_ON(!path);
data_size = sizeof(*dir_item) + name_len;
dir_item = insert_with_overflow(trans, root, path, key, data_size,
name, name_len);
Index: btrfs-unstable-standalone/export.c
===
--- btrfs-unstable-standalone.orig/export.c 2008-12-29 21:25:33.317589186
+0100
+++ btrfs-unstable-standalone/export.c 2008-12-29 21:26:46.658692859 +0100
@@ -146,6 +146,7 @@
int ret;
path = btrfs_alloc_path();
+ BUG_ON(!path);
key.objectid = dir-i_ino;
btrfs_set_key_type(key, BTRFS_INODE_REF_KEY);
Index: btrfs-unstable-standalone/extent-tree.c
===
--- btrfs-unstable-standalone.orig/extent-tree.c2008-12-29
21:26:52.133589589 +0100
+++ btrfs-unstable-standalone/extent-tree.c 2008-12-29 21:29:33.000589414
+0100
@@ -1337,6 +1337,7 @@
WARN_ON(num_bytes root-sectorsize);
path = btrfs_alloc_path();
+ BUG_ON(!path);
path-reada = 1;
key.objectid = bytenr;
key.offset = num_bytes;
@@ -1377,6 +1378,7 @@
key.type = BTRFS_EXTENT_ITEM_KEY;
path = btrfs_alloc_path();
+ BUG_ON(!path);
ret = btrfs_search_slot(NULL, extent_root, key, path, 0, 0);
if (ret 0)
goto out;
@@ -2132,6 +2134,7 @@
int num_inserts = 0, max_inserts;
path = btrfs_alloc_path();
+ BUG_ON(!path);
INIT_LIST_HEAD(insert_list);
INIT_LIST_HEAD(update_list);
Index: btrfs-unstable-standalone/file-item.c
===
--- btrfs-unstable-standalone.orig/file-item.c 2008-12-29 21:30:59.441588913
+0100
+++ btrfs-unstable-standalone/file-item.c 2008-12-29 21:31:58.836588923
+0100
@@ -160,6 +160,7 @@
struct extent_io_tree *io_tree = BTRFS_I(inode)-io_tree;
path = btrfs_alloc_path();
+ BUG_ON(!path);
if (bio-bi_size PAGE_CACHE_SIZE * 8)
path-reada = 2;
@@ -506,6 +507,7 @@
root = root-fs_info-csum_root;
path = btrfs_alloc_path();
+ BUG_ON(!path);
while(1) {
key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
Index: btrfs-unstable-standalone/file.c
===
--- btrfs-unstable-standalone.orig/file.c 2008-12-29 21:30:18.940839123
+0100
+++ btrfs-unstable-standalone/file.c2008-12-29 21:30:38.941774195 +0100
@@ -293,6 +293,7 @@
u64 extent_end = 0;
path = btrfs_alloc_path();
+ BUG_ON(!path);
ret = btrfs_lookup_file_extent(NULL, root, path, inode-i_ino,
last_offset, 0);
while(1) {
Index: btrfs-unstable-standalone/inode.c
===
--- btrfs-unstable-standalone.orig/inode.c 2008-12-29 21:32:03.109588918
+0100
+++ btrfs-unstable-standalone/inode.c 2008-12-29 21:35:12.321588484 +0100
@@ -2504,8 +2504,8 @@
if (root-ref_cows)
btrfs_drop_extent_cache(inode, new_size (~mask), (u64)-1, 0);
path = btrfs_alloc_path();
- path-reada = -1;
BUG_ON(!path);
+ path-reada = -1;
/* FIXME, add redo link to tree so we don't leak on crash */
key.objectid = inode-i_ino;
@@ -3182,6 +3182,7 @@
filp-f_pos = 2;
}
path = btrfs_alloc_path();
+ BUG_ON(!path);
path-reada = 2;
btrfs_set_key_type(key, key_type);
Index: btrfs-unstable-standalone/ioctl.c
===
--- btrfs-unstable-standalone.orig/ioctl.c 2008-12-29 21:35:26.854838809
+0100
+++ btrfs-unstable-standalone/ioctl.c 2008-12-29 21:36:27.742591734 +0100
@@ -292,6 +292,7 @@
u64 test_oid;
u64 parent_oid = BTRFS_I(dir-d_inode)-root-root_key.objectid;
+ BUG_ON(!path);
test_oid = snap_src-root_key.objectid;
Re: Selective Compression/Encryption
El Tue, 9 Dec 2008 13:09:51 -0500, Lee Trager [EMAIL PROTECTED] escribió: It does seem that doing it with volumes would limit user control and add lots of complexity to such a simple task. IMHO, WRT compression it's the contrary. Compression on a per-file basis has never been very succesful (just look at how many windows users use it) because it implies taking a decision for every file on the system. OTOH, volume-level is just a single option to be enabled. I'm of course not arguing that file-level compression shouldn't be possible, im just saying that is way more difficult to administer and that most people (including sysadmins) is most likely to use compression in a per-volume basis. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
possible circular locking dependency detected
I got this lockdep warning while running tiobench on a clean btrfs filesystem
with the latest code available (commit 2c41b36dd2f9fb5dee150f20c84895496e0642f2)
But it was a purely read-only workload: only root could write to the
filesystem and I was running tiobench as an user, which was spitting
denied permission errors.
[ 5177.201587] ===
[ 5177.201594] [ INFO: possible circular locking dependency detected ]
[ 5177.201601] 2.6.28-rc5-dirty #7
[ 5177.201604] ---
[ 5177.201610] btrfs-transacti/9012 is trying to acquire lock:
[ 5177.201615] (cache-alloc_mutex){--..}, at: [a03d9e57]
btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.201648]
[ 5177.201650] but task is already holding lock:
[ 5177.201654] (fs_info-pinned_mutex){--..}, at: [a039eb53]
btrfs_finish_extent_commit+0x33/0x100 [btrfs]
[ 5177.201692]
[ 5177.201693] which lock already depends on the new lock.
[ 5177.201695]
[ 5177.201698]
[ 5177.201699] the existing dependency chain (in reverse order) is:
[ 5177.201704]
[ 5177.201705] - #1 (fs_info-pinned_mutex){--..}:
[ 5177.201712][8026cb99] __lock_acquire+0x13c9/0x1970
[ 5177.201722][8026d196] lock_acquire+0x56/0x80
[ 5177.201728][804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.201736][a0396c07] add_new_free_space+0x37/0xe0 [btrfs]
[ 5177.201755][a0396f62] cache_block_group+0x2b2/0x320 [btrfs]
[ 5177.201774][a0397294] find_free_extent+0x2c4/0x640 [btrfs]
[ 5177.201792][a0397704] __btrfs_reserve_extent+0xf4/0x310
[btrfs]
[ 5177.201811][a03995bc] btrfs_alloc_extent+0x4c/0xc0 [btrfs]
[ 5177.201829][a0399691] btrfs_alloc_free_block+0x61/0xa0
[btrfs]
[ 5177.201848][a0388fd6] __btrfs_cow_block+0x966/0xe00 [btrfs]
[ 5177.201865][a0389ca6] btrfs_cow_block+0x136/0x330 [btrfs]
[ 5177.201883][a038fdc4] btrfs_search_slot+0x294/0xb70 [btrfs]
[ 5177.201901][a03a2838] btrfs_lookup_inode+0x38/0xb0 [btrfs]
[ 5177.201920][a03ad86b] btrfs_update_inode+0x4b/0xd0 [btrfs]
[ 5177.201940][a03b07cd] btrfs_dirty_inode+0x4d/0x70 [btrfs]
[ 5177.201961][802edc1a] __mark_inode_dirty+0x3a/0x1d0
[ 5177.201968][802e2438] touch_atime+0xd8/0x140
[ 5177.201975][802dccc6] vfs_readdir+0xc6/0xd0
[ 5177.201983][802dce38] sys_getdents+0x88/0xe0
[ 5177.201989][8020bb7b] system_call_fastpath+0x16/0x1b
[ 5177.201997][] 0x
[ 5177.202024]
[ 5177.202025] - #0 (cache-alloc_mutex){--..}:
[ 5177.202033][8026cce2] __lock_acquire+0x1512/0x1970
[ 5177.202039][8026d196] lock_acquire+0x56/0x80
[ 5177.202046][804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.202053][a03d9e57] btrfs_add_free_space+0x27/0x70
[btrfs]
[ 5177.202072][a0397cd2]
btrfs_update_pinned_extents+0x172/0x1d0 [btrfs]
[ 5177.202091][a039eb92]
btrfs_finish_extent_commit+0x72/0x100 [btrfs]
[ 5177.202110][a03a9fc5] btrfs_commit_transaction+0x6f5/0x8b0
[btrfs]
[ 5177.202130][a03a44c1] transaction_kthread+0x231/0x270
[btrfs]
[ 5177.202149][80259cde] kthread+0x4e/0x90
[ 5177.202157][8020ccc9] child_rip+0xa/0x11
[ 5177.202163][] 0x
[ 5177.202170]
[ 5177.202171] other info that might help us debug this:
[ 5177.202173]
[ 5177.202177] 3 locks held by btrfs-transacti/9012:
[ 5177.202181] #0: (fs_info-transaction_kthread_mutex){--..}, at:
[a03a4383] transaction_kthread+0xf3/0x270 [btrfs]
[ 5177.202206] #1: (fs_info-tree_reloc_mutex){--..}, at:
[a03a9c16] btrfs_commit_transaction+0x346/0x8b0 [btrfs]
[ 5177.202231] #2: (fs_info-pinned_mutex){--..}, at: [a039eb53]
btrfs_finish_extent_commit+0x33/0x100 [btrfs]
[ 5177.202254]
[ 5177.202255] stack backtrace:
[ 5177.202260] Pid: 9012, comm: btrfs-transacti Not tainted 2.6.28-rc5-dirty #7
[ 5177.202265] Call Trace:
[ 5177.202271] [8026b3a8] print_circular_bug_tail+0xd8/0xe0
[ 5177.202278] [8026cce2] __lock_acquire+0x1512/0x1970
[ 5177.202285] [8026899c] ? find_usage_backwards+0xdc/0x120
[ 5177.202306] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202312] [8026d196] lock_acquire+0x56/0x80
[ 5177.202329] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202337] [804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.202354] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202372] [a03d9e57] btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202391] [a0397cd2] btrfs_update_pinned_extents+0x172/0x1d0
[btrfs]
[ 5177.202410] [a039eb92]
[BUG] kernel BUG at btrfs/extent-tree.c:2462
hi doing a defragmentation on a full disk ( fs_mark -d test -s 20480 -D 64 -t 8 -F ) btrfsctl return with segmentation fault, the filesystem becomes unresponsive and dmesg show this kernel BUG: [16790.147270] space info full 1 [39828.979719] space info full 4 [39828.979725] allocation failed flags 4, wanted 4096 [39828.979728] space_info has 525475840 free, is full [39828.979730] block group 2176843776 has 1073741824 bytes, 532398080 used 21934080 pinned [39828.983715] 42987 blocks of free space at or bigger than bytes is [39828.983718] block group 4194304 has 8388608 bytes, 2322432 used 0 pinned [39828.983737] 168 blocks of free space at or bigger than bytes is [39828.983782] [ cut here ] [39828.983786] kernel BUG at /usr/src/kernel-development/btrfs-unstable/fs/btrfs/extent-tree.c:2462! [39828.983790] invalid opcode: [1] SMP [39828.983794] CPU 0 [39828.983797] Modules linked in: btrfs libcrc32c af_packet radeon drm binfmt_misc rfcomm l2cap bluetooth ppdev ipv6 cpufreq_ondemand cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats freq_table sbs sbshc video output wmi container pci_slot battery iptable_filter ip_tables x_tables dm_crypt crypto_blkcipher dm_mod ac sbp2 lp snd_via82xxgameport snd_via82xx_modem snd_pcm_oss snd_mixer_oss snd_ac97_codec ac97_bus snd_mpu401_uart snd_pcm snd_seq_dummy psmouse serio_raw snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device k8temp snd snd_page_alloc soundcore i2c_viapro i2c_core parport_pc parport shpchp pci_hotplug button evdev usbhid hid ext3 jbd mbcache sr_mod cdrom sg sd_mod crc_t10dif pata_via pata_acpi ata_generic sata_via uhci_hcd ehci_hcd libata usbcore ohci1394 scsi_mod dock ieee1394 sky2 thermal processor fan fbcon tileblit font bitblit softcursor uvesafb cn fuse [39828.983863] Pid: 12303, comm: btrfsctl Not tainted 2.6.27-4-generic #1 [39828.983865] RIP: 0010:[a04a971d] [a04a971d] __btrfs_reserve_extent+0x30d/0x3b0 [btrfs] [39828.983893] RSP: :88000a5cda18 EFLAGS: 00010206 [39828.983895] RAX: 88003d97aec0 RBX: 8800175d3480 RCX: [39828.983897] RDX: RSI: 0082 RDI: 880032f27e28 [39828.983899] RBP: 88000a5cda88 R08: R09: 0006 [39828.983902] R10: 88000a5cd788 R11: 88008a5cd897 R12: 8800175d34ac [39828.983904] R13: 1000 R14: 880032f27e18 R15: 880032f27e28 [39828.983907] FS: 7fa4665e7730() GS:806ffa80() knlGS:f731e920 [39828.983909] CS: 0010 DS: ES: CR0: 8005003b [39828.983911] CR2: 7f03759d7000 CR3: 3cd74000 CR4: 06e0 [39828.983914] DR0: DR1: DR2: [39828.983916] DR3: DR6: 0ff0 DR7: 0400 [39828.983919] Process btrfsctl (pid: 12303, threadinfo 88000a5cc000, task 88001db1) [39828.983920] Stack: c1bef000 88000a5cdb38 [39828.983928] e204 c1bef000 0001 88000c72e000 [39828.983932] 880032f27e18 1000 88000a5cdb38 880020701400 [39828.983936] Call Trace: [39828.983958] [a04a9826] btrfs_alloc_extent+0x66/0xd0 [btrfs] [39828.983974] [a04a98fa] btrfs_alloc_free_block+0x6a/0xa0 [btrfs] [39828.983990] [a04cfd9a] ? read_extent_buffer_pages+0x35a/0x400 [btrfs] [39828.984005] [a049e553] __btrfs_cow_block+0x4d3/0x6c0 [btrfs] [39828.984007] [a04b21c4] ? btree_read_extent_buffer_pages+0x74/0xd0 [btrfs] [39828.984007] [a04a028d] btrfs_realloc_node+0x40d/0x660 [btrfs] [39828.984007] [a04cc6c9] ? read_extent_buffer+0xd9/0x190 [btrfs] [39828.984007] [a04bf2ed] btrfs_defrag_leaves+0x2fd/0x3c0 [btrfs] [39828.984007] [8051b236] ? _spin_lock_irq+0x16/0x20 [39828.984007] [a04ca47b] ? count_range_bits+0xfb/0x170 [btrfs] [39828.984007] [a04b4bdf] btrfs_defrag_root+0x7f/0x100 [btrfs] [39828.984007] [a04d5fba] btrfs_ioctl+0x2fa/0x450 [btrfs] [39828.984007] [802c7d05] ? vma_link+0x85/0x140 [39828.984007] [802f9e76] vfs_ioctl+0x36/0xb0 [39828.984007] [802fa173] do_vfs_ioctl+0x283/0x2f0 [39828.984007] [802fa281] sys_ioctl+0xa1/0xb0 [39828.984007] [8021288a] system_call_fastpath+0x16/0x1b [39828.984007] [39828.984007] [39828.984007] Code: e0 4c 89 ff e8 35 1c 07 e0 4d 8b 74 24 38 49 83 c4 38 4c 89 65 d0 4c 3b 75 d0 49 8b 06 0f 18 08 75 60 4c 89 ff e8 c4 3d d8 df 90 0f 0b eb fe 0f 1f 80 00 00 00 00 48 8b 98 20 1a 00 00 48 23 98 [39828.984007] RIP [a04a971d] __btrfs_reserve_extent+0x30d/0x3b0 [btrfs] [39828.984007] RSP 88000a5cda18 [39828.984215] ---[ end trace 9ded69dedbc7fc63 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to [EMAIL PROTECTED] More majordomo info at
