Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

2017-07-04 Thread Markus Trippelsdorf 
On 2017.07.04 at 10:31 -0500, Goldwyn Rodrigues wrote:
> 
> 
> On 07/04/2017 02:45 AM, Markus Trippelsdorf wrote:
> > On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote:
> >> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
> >> Author: Goldwyn Rodrigues <rgold...@suse.com>
> >> Date:   Tue Jun 20 07:05:49 2017 -0500
> >>
> >> btrfs: nowait aio support
> >>
> >> apparently breaks several shell related features on my system.
> > 
> > Here is a simple testcase:
> > 
> >  % echo "foo" >> test
> >  % echo "foo" >> test
> >  % cat test
> >  foo
> >  %
> > 
> 
> Thanks for testing.
> Yes, pos must be set with iocb->ki_pos for appends. I should not have
> removed the initialization. Could you try this patch?

It fixes the issue. Thank you.

-- 
Markus
--
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: Commit edf064e7c (btrfs: nowait aio support) breaks shells

2017-07-04 Thread Markus Trippelsdorf 
On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote:
> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
> Author: Goldwyn Rodrigues <rgold...@suse.com>
> Date:   Tue Jun 20 07:05:49 2017 -0500
> 
> btrfs: nowait aio support
> 
> apparently breaks several shell related features on my system.

Here is a simple testcase:

 % echo "foo" >> test
 % echo "foo" >> test
 % cat test
 foo
 %

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

Commit edf064e7c (btrfs: nowait aio support) breaks shells

2017-07-03 Thread Markus Trippelsdorf 
commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
Author: Goldwyn Rodrigues 
Date:   Tue Jun 20 07:05:49 2017 -0500

btrfs: nowait aio support

apparently breaks several shell related features on my system.
In zsh history stopped working, because no new entries are added
anymore.
I fist noticed the issue when I tried to build mplayer. It uses a shell
script to generate a help_mp.h file:

  % help/help_create.sh help/help_mp-en.h UTF-8

This file gets corrupted:

--- help_mp_good.h  2017-07-04 05:38:33.161640826 +0200
+++ help_mp_bad.h   2017-07-04 05:51:00.650730726 +0200
@@ -1,14 +1,8 @@
-/* WARNING! This is a generated file, do NOT edit.
- * See the help/ subdirectory for the editable files. */
 
 -#ifndef MPLAYER_HELP_MP_H
 -#define MPLAYER_HELP_MP_H
 -
 -#include 
 -#include "config.h"
 +#endif /* MPLAYER_HELP_MP_H */
 +he English master file */
  
  -// $Revision: 37846 $
  -// MASTER FILE. Use this file as base for translations.
  + for translations.
...
(I have attached the testcase.)

/dev/sdc3 on / type btrfs 
(rw,noatime,lazytime,compress=lzo,ssd,noacl,space_cache=v2,subvolid=5,subvol=/) 
 # cat /sys/block/sdc/queue/scheduler
[none] mq-deadline 

-- 
Markus


test.tar.bz2
Description: Binary data

Re: OOM killer and Btrfs

2016-09-04 Thread Markus Trippelsdorf 
On 2016.09.04 at 11:59 +0200, Francesco Turco wrote:
> I use Btrfs on a Gentoo Linux system with kernel 4.7.2. When my computer
> is under heavy I/O load some application often crashes, for example
> ClamAV, Firefox or Portage. I suspect the problem is due to Btrfs, but I
> may be wrong.
> 
> These are the most recent error messages from journalctl, but I have
> many other similar ones in my logs:
> 
> *** BEGIN ***
> 
> Sep 04 10:13:26 desktop kernel: gpg-agent invoked oom-killer:
> gfp_mask=0x27080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK),
> order=2, oom_
> 
> Is the problem already known? Should I report a bug? Is there a patch I
> can try? Thanks.

This issue was recently fixed by:

commit 6b4e3181d7bd5ca5ab6f45929e4a5ffa7ab4ab7f
Author: Michal Hocko 
Date:   Thu Sep 1 16:14:41 2016 -0700

mm, oom: prevent premature OOM killer invocation for high order request

It will be backported to the 4.7.x stable kernel, too.

-- 
Markus
--
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: OOM killer invoked during btrfs send/recieve on otherwise idle machine

2016-07-31 Thread Markus Trippelsdorf 
On 2016.07.31 at 17:10 +0200, Michal Hocko wrote:
> [CC Mel and linux-mm]
> 
> On Sun 31-07-16 07:11:21, Markus Trippelsdorf wrote:
> > Tonight the OOM killer got invoked during backup of /:
> > 
> > [Jul31 01:56] kthreadd invoked oom-killer: 
> > gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, 
> > oom_score_adj=0
> 
> This a kernel stack allocation.
> 
> > [  +0.04] CPU: 3 PID: 2 Comm: kthreadd Not tainted 
> > 4.7.0-06816-g797cee982eef-dirty #37
> > [  +0.00] Hardware name: System manufacturer System Product 
> > Name/M4A78T-E, BIOS 350304/13/2011
> > [  +0.02]   813c2d58 8802168e7d48 
> > 002ec4ea
> > [  +0.02]  8118eb9d 01b8 0440 
> > 03b0
> > [  +0.02]  8802133fe400 002ec4ea 81b8ac9c 
> > 0006
> > [  +0.01] Call Trace:
> > [  +0.04]  [] ? dump_stack+0x46/0x6e
> > [  +0.03]  [] ? dump_header.isra.11+0x4c/0x1a7
> > [  +0.02]  [] ? oom_kill_process+0x2ab/0x460
> > [  +0.01]  [] ? out_of_memory+0x2e3/0x380
> > [  +0.02]  [] ? 
> > __alloc_pages_slowpath.constprop.124+0x1d32/0x1e40
> > [  +0.01]  [] ? __alloc_pages_nodemask+0x10c/0x120
> > [  +0.02]  [] ? copy_process.part.72+0xea/0x17a0
> > [  +0.02]  [] ? pick_next_task_fair+0x915/0x1520
> > [  +0.01]  [] ? kthread_flush_work_fn+0x20/0x20
> > [  +0.01]  [] ? kernel_thread+0x7a/0x1c0
> > [  +0.01]  [] ? kthreadd+0xd2/0x120
> > [  +0.02]  [] ? ret_from_fork+0x1f/0x40
> > [  +0.01]  [] ? kthread_stop+0x100/0x100
> > [  +0.01] Mem-Info:
> > [  +0.03] active_anon:5882 inactive_anon:60307 isolated_anon:0
> >active_file:1523729 inactive_file:223965 isolated_file:0
> >unevictable:1970 dirty:130014 writeback:40735 unstable:0
> >slab_reclaimable:179690 slab_unreclaimable:8041
> >mapped:6771 shmem:3 pagetables:592 bounce:0
> >free:11374 free_pcp:54 free_cma:0
> > [  +0.04] Node 0 active_anon:23528kB inactive_anon:241228kB 
> > active_file:6094916kB inactive_file:895860kB unevictable:7880kB 
> > isolated(anon):0kB isolated(file):0kB mapped:27084kB dirty:520056kB 
> > writeback:162940kB shmem:12kB writeback_tmp:0kB unstable:0kB 
> > pages_scanned:32 all_unreclaimable? no
> > [  +0.02] DMA free:15908kB min:20kB low:32kB high:44kB active_anon:0kB 
> > inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
> > writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
> > slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB 
> > bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [  +0.01] lowmem_reserve[]: 0 3486 7953 7953
> > [  +0.04] DMA32 free:23456kB min:4996kB low:8564kB high:12132kB 
> > active_anon:2480kB inactive_anon:10564kB active_file:2559792kB 
> > inactive_file:478680kB unevictable:0kB writepending:365292kB 
> > present:3652160kB managed:3574264kB mlocked:0kB slab_reclaimable:437456kB 
> > slab_unreclaimable:12304kB kernel_stack:144kB pagetables:28kB bounce:0kB 
> > free_pcp:212kB local_pcp:0kB free_cma:0kB
> > [  +0.01] lowmem_reserve[]: 0 0 4466 4466
> > [  +0.03] Normal free:6132kB min:6400kB low:10972kB high:15544kB 
> > active_anon:21048kB inactive_anon:230664kB active_file:3535124kB 
> > inactive_file:417312kB unevictable:7880kB writepending:318020kB 
> > present:4718592kB managed:4574096kB mlocked:7880kB 
> > slab_reclaimable:281304kB slab_unreclaimable:19860kB kernel_stack:2944kB 
> > pagetables:2340kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [  +0.00] lowmem_reserve[]: 0 0 0 0
> > [  +0.02] DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 
> > 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15908kB
> > [  +0.05] DMA32: 4215*4kB (UMEH) 319*8kB (UMH) 5*16kB (H) 2*32kB (H) 
> > 2*64kB (H) 1*128kB (H) 0*256kB 1*512kB (H) 1*1024kB (H) 1*2048kB (H) 
> > 0*4096kB = 23396kB
> > [  +0.06] Normal: 650*4kB (UMH) 4*8kB (UH) 27*16kB (H) 23*32kB (H) 
> > 17*64kB (H) 11*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6296kB
> 
> The memory is quite fragmented but there are order-2+ free blocks. They
> seem to be in the high atomic reserves but we should release them.
> Is this reproducible? If yes, could you try with the 4.7 kernel please?

It never happened before and it only happend once yet. I will continue
to run the latest git kernel and let you know if it happens again.

(I did copy several git trees to my root partition yesterday, so the
incremental btrfs stream was larger than usual.)

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

OOM killer invoked during btrfs send/recieve on otherwise idle machine

2016-07-30 Thread Markus Trippelsdorf 
Tonight the OOM killer got invoked during backup of /:

[Jul31 01:56] kthreadd invoked oom-killer: 
gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, oom_score_adj=0
[  +0.04] CPU: 3 PID: 2 Comm: kthreadd Not tainted 
4.7.0-06816-g797cee982eef-dirty #37
[  +0.00] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[  +0.02]   813c2d58 8802168e7d48 
002ec4ea
[  +0.02]  8118eb9d 01b8 0440 
03b0
[  +0.02]  8802133fe400 002ec4ea 81b8ac9c 
0006
[  +0.01] Call Trace:
[  +0.04]  [] ? dump_stack+0x46/0x6e
[  +0.03]  [] ? dump_header.isra.11+0x4c/0x1a7
[  +0.02]  [] ? oom_kill_process+0x2ab/0x460
[  +0.01]  [] ? out_of_memory+0x2e3/0x380
[  +0.02]  [] ? 
__alloc_pages_slowpath.constprop.124+0x1d32/0x1e40
[  +0.01]  [] ? __alloc_pages_nodemask+0x10c/0x120
[  +0.02]  [] ? copy_process.part.72+0xea/0x17a0
[  +0.02]  [] ? pick_next_task_fair+0x915/0x1520
[  +0.01]  [] ? kthread_flush_work_fn+0x20/0x20
[  +0.01]  [] ? kernel_thread+0x7a/0x1c0
[  +0.01]  [] ? kthreadd+0xd2/0x120
[  +0.02]  [] ? ret_from_fork+0x1f/0x40
[  +0.01]  [] ? kthread_stop+0x100/0x100
[  +0.01] Mem-Info:
[  +0.03] active_anon:5882 inactive_anon:60307 isolated_anon:0
   active_file:1523729 inactive_file:223965 isolated_file:0
   unevictable:1970 dirty:130014 writeback:40735 unstable:0
   slab_reclaimable:179690 slab_unreclaimable:8041
   mapped:6771 shmem:3 pagetables:592 bounce:0
   free:11374 free_pcp:54 free_cma:0
[  +0.04] Node 0 active_anon:23528kB inactive_anon:241228kB 
active_file:6094916kB inactive_file:895860kB unevictable:7880kB 
isolated(anon):0kB isolated(file):0kB mapped:27084kB dirty:520056kB 
writeback:162940kB shmem:12kB writeback_tmp:0kB unstable:0kB pages_scanned:32 
all_unreclaimable? no
[  +0.02] DMA free:15908kB min:20kB low:32kB high:44kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[  +0.01] lowmem_reserve[]: 0 3486 7953 7953
[  +0.04] DMA32 free:23456kB min:4996kB low:8564kB high:12132kB 
active_anon:2480kB inactive_anon:10564kB active_file:2559792kB 
inactive_file:478680kB unevictable:0kB writepending:365292kB present:3652160kB 
managed:3574264kB mlocked:0kB slab_reclaimable:437456kB 
slab_unreclaimable:12304kB kernel_stack:144kB pagetables:28kB bounce:0kB 
free_pcp:212kB local_pcp:0kB free_cma:0kB
[  +0.01] lowmem_reserve[]: 0 0 4466 4466
[  +0.03] Normal free:6132kB min:6400kB low:10972kB high:15544kB 
active_anon:21048kB inactive_anon:230664kB active_file:3535124kB 
inactive_file:417312kB unevictable:7880kB writepending:318020kB 
present:4718592kB managed:4574096kB mlocked:7880kB slab_reclaimable:281304kB 
slab_unreclaimable:19860kB kernel_stack:2944kB pagetables:2340kB bounce:0kB 
free_pcp:0kB local_pcp:0kB free_cma:0kB
[  +0.00] lowmem_reserve[]: 0 0 0 0
[  +0.02] DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15908kB
[  +0.05] DMA32: 4215*4kB (UMEH) 319*8kB (UMH) 5*16kB (H) 2*32kB (H) 2*64kB 
(H) 1*128kB (H) 0*256kB 1*512kB (H) 1*1024kB (H) 1*2048kB (H) 0*4096kB = 23396kB
[  +0.06] Normal: 650*4kB (UMH) 4*8kB (UH) 27*16kB (H) 23*32kB (H) 17*64kB 
(H) 11*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6296kB
[  +0.05] 1749526 total pagecache pages
[  +0.01] 150 pages in swap cache
[  +0.01] Swap cache stats: add 1222, delete 1072, find 2366/2401
[  +0.00] Free swap  = 4091520kB
[  +0.01] Total swap = 4095996kB
[  +0.00] 2096686 pages RAM
[  +0.01] 0 pages HighMem/MovableOnly
[  +0.00] 55619 pages reserved
[  +0.01] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents 
oom_score_adj name
[  +0.04] [  153] 0   153 4087  406   9   3  104
 -1000 udevd
[  +0.01] [  181] 0   181 5718 1169  15   3  143
 0 syslog-ng
[  +0.01] [  187]   102   18788789 5137  53   3  663
 0 mpd
[  +0.02] [  188] 0   18822278 1956  16   30
 0 ntpd
[  +0.01] [  189] 0   189 4973  859  14   3  188
 0 cupsd
[  +0.01] [  192] 0   192 2680  391  10   3   21
 0 fcron
[  +0.01] [  219] 0   219 4449  506  13   30
 0 login
[  +0.02] [  220] 0   220 2876  368   9   30
 0 agetty
[  +0.01] [  222]31   2222719320995  57

Re: btrfs_destroy_inode WARN_ON.

2016-03-28 Thread Markus Trippelsdorf 
On 2016.03.28 at 10:05 -0400, Josef Bacik wrote:
> >Mar 24 10:37:27 x4 kernel: WARNING: CPU: 3 PID: 11838 at 
> >fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x22b/0x2a0
> 
> I saw this running some xfstests on our internal kernels but haven't been
> able to reproduce it on my latest enospc work (which is obviously perfect).
> What were you doing when you tripped this?  I'd like to see if I actually
> did fix it or if I still need to run it down.  Thanks,

I cannot really tell. Looking at the backtrace, both Dave and I were
running rm. 
This warning happened just once on my machine, so the issue is obviously
very hard to trigger.

-- 
Markus
--
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: btrfs_destroy_inode WARN_ON.

2016-03-25 Thread Markus Trippelsdorf 
On 2016.03.24 at 18:54 -0400, Dave Jones wrote:
> Just hit this on a tree from earlier this morning, v4.5-11140 or so.
> 
> WARNING: CPU: 2 PID: 32570 at fs/btrfs/inode.c:9261 
> btrfs_destroy_inode+0x389/0x3f0 [btrfs]
> CPU: 2 PID: 32570 Comm: rm Not tainted 4.5.0-think+ #14
>  c039baf9 ef721ef0 88025966fc08 8957bcdb
>    88025966fc50 890b41f1
>  88045d918040 242d4eed6048 88024eed6048 88024eed6048
> Call Trace:
>  [] ? btrfs_destroy_inode+0x389/0x3f0 [btrfs]
>  [] dump_stack+0x68/0x9d
>  [] __warn+0x111/0x130
>  [] warn_slowpath_null+0x1d/0x20
>  [] btrfs_destroy_inode+0x389/0x3f0 [btrfs]
>  [] destroy_inode+0x67/0x90
>  [] evict+0x1b7/0x240
>  [] iput+0x3ae/0x4e0
>  [] ? dput+0x20e/0x460
>  [] do_unlinkat+0x256/0x440
>  [] ? do_rmdir+0x350/0x350
>  [] ? syscall_trace_enter_phase1+0x87/0x260
>  [] ? enter_from_user_mode+0x50/0x50
>  [] ? __lock_is_held+0x25/0xd0
>  [] ? mark_held_locks+0x22/0xc0
>  [] ? syscall_trace_enter_phase2+0x12d/0x3d0
>  [] ? SyS_rmdir+0x20/0x20
>  [] SyS_unlinkat+0x1b/0x30
>  [] do_syscall_64+0xf4/0x240
>  [] entry_SYSCALL64_slow_path+0x25/0x25
> ---[ end trace a48ce4e6a1b5e409 ]---
> 
> 
> That's WARN_ON(BTRFS_I(inode)->csum_bytes);
> 
> *maybe* it's a bad disk, but there's no indication in dmesg of anything awry.
> Spinning rust on SATA, nothing special.

Same thing here:

Mar 24 10:37:27 x4 kernel: [ cut here ]
Mar 24 10:37:27 x4 kernel: WARNING: CPU: 3 PID: 11838 at fs/btrfs/inode.c:9261 
btrfs_destroy_inode+0x22b/0x2a0
Mar 24 10:37:27 x4 kernel: CPU: 3 PID: 11838 Comm: rm Not tainted 
4.5.0-11787-ga24e3d414e59-dirty #64
Mar 24 10:37:27 x4 kernel: Hardware name: System manufacturer System Product 
Name/M4A78T-E, BIOS 350304/13/2011
Mar 24 10:37:27 x4 kernel:  813c0d1a 81b8bb84 
812ffd0b
Mar 24 10:37:27 x4 kernel: 81099a9a  880149b86088 
88021585f000
Mar 24 10:37:27 x4 kernel: 812ffd0b  88005f526000 

Mar 24 10:37:27 x4 kernel: Call Trace:
Mar 24 10:37:27 x4 kernel: [] ? dump_stack+0x46/0x6c
Mar 24 10:37:27 x4 kernel: [] ? 
btrfs_destroy_inode+0x22b/0x2a0
Mar 24 10:37:27 x4 kernel: [] ? warn_slowpath_null+0x5a/0xe0
Mar 24 10:37:27 x4 kernel: [] ? 
btrfs_destroy_inode+0x22b/0x2a0
Mar 24 10:37:27 x4 kernel: [] ? do_unlinkat+0x13c/0x3e0
Mar 24 10:37:27 x4 kernel: [] ? 
entry_SYSCALL_64_fastpath+0x13/0x8f
Mar 24 10:37:27 x4 kernel: ---[ end trace e9bae5be848e7a9e ]---

-- 
Markus
--
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: !PageLocked BUG_ON hit in clear_page_dirty_for_io

2015-12-10 Thread Markus Trippelsdorf 
On 2015.12.08 at 23:25 -0500, Dave Jones wrote:
> Not sure if I've already reported this one, but I've been seeing this
> a lot this last couple days.
> 
> kernel BUG at mm/page-writeback.c:2654!

Just hit the same issue trying to build ghc-7.10.3:

[55704.436096] [ cut here ]
[55704.436155] kernel BUG at mm/page-writeback.c:2654!
[55704.436213] invalid opcode:  [#1] SMP 
[55704.436261] CPU: 2 PID: 17177 Comm: ghc Not tainted 
4.4.0-rc4-00060-g9a0f76fde9ad-dirty #69
[55704.436370] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[55704.436491] task: 88015c2c1d40 ti: 880199268000 task.ti: 
880199268000
[55704.436585] RIP: 0010:[]  [] 
clear_page_dirty_for_io+0xdd/0x180
[55704.436710] RSP: 0018:88019926bcd0  EFLAGS: 00010246
[55704.436770] RAX: 4868 RBX: ea00029f2080 RCX: 
[55704.436860] RDX:  RSI: 0286 RDI: ea00029f2080
[55704.436949] RBP: 8801c7900e30 R08: a2bc9694357c R09: 
[55704.437037] R10:  R11: 88015c2c1da0 R12: 8801c7900e30
[55704.437131] R13: 88019926bda0 R14: 0007 R15: ea00029f2080
[55704.437222] FS:  7f79ba21e700() GS:88021fd0() 
knlGS:
[55704.437326] CS:  0010 DS:  ES:  CR0: 8005003b
[55704.437395] CR2: 7fffa6d2cff8 CR3: 7ee1b000 CR4: 06e0
[55704.437485] Stack:
[55704.437495]  88019926bd38 88019926be78 8801c7900e30 
812f81ae
[55704.437595]  88019926bdd8 0040  

[55704.437693]  8801c7900cf0 000e 000e 

[55704.437792] Call Trace:
[55704.437812]  [] ? 
extent_write_cache_pages.isra.39.constprop.74+0x14e/0x320
[55704.437925]  [] ? extent_writepages+0x4b/0x120
[55704.437998]  [] ? __start_delalloc_inodes+0x3a0/0x3a0
[55704.438080]  [] ? do_writepages+0x25/0x80
[55704.438152]  [] ? do_signal+0x2c7/0x540
[55704.438228]  [] ? filemap_flush+0x65/0xa0
[55704.438303]  [] ? btrfs_release_file+0x2e/0x40
[55704.438378]  [] ? fput+0xcc/0x1c0
[55704.438438]  [] ? task_work_run+0x6c/0xa0
[55704.438510]  [] ? syscall_return_slowpath+0xcc/0xe0
[55704.438591]  [] ? int_ret_from_sys_call+0x25/0x8f
[55704.438672] Code: e1 81 74 19 49 8b 44 24 18 48 3b 05 be e2 d2 00 0f 84 8a 
00 00 00 48 8b a8 c8 00 00 00 f0 0f ba 33 04 72 82 31 c0 e9 76 ff ff ff <0f> 0b 
48 c7 c0 60 ce e1 81 e9 59 ff ff ff 48 89 df e8 4d 00 01 
[55704.439055] RIP  [] clear_page_dirty_for_io+0xdd/0x180
[55704.439144]  RSP 
[55704.475600] ---[ end trace 09f06afe4a05a024 ]---

-- 
Markus
--
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: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()

2015-03-10 Thread Markus Trippelsdorf 
On 2015.03.07 at 09:35 +, Filipe David Manana wrote:
 On Tue, Mar 3, 2015 at 2:13 PM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2015.03.02 at 14:29 +0100, Markus Trippelsdorf wrote:
  On 2015.03.02 at 12:07 +, Filipe David Manana wrote:
[83159.038708] [ cut here ]
[83159.038716] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 
btrfs_destroy_inode+0x278/0x2a0()
[83159.038718] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
4.0.0-rc1-dirty #104
[83159.038719] Hardware name: System manufacturer System Product 
Name/M4A78T-E, BIOS 350304/13/2011
[83159.038720]   810f 8168d723 

[83159.038722]  8106d2d2  88005756edf0 
880215805800
[83159.038723]  880169477eb8 88005756edf0 8121bab8 
880100675000
[83159.038725] Call Trace:
[83159.038728]  [8168d723] ? dump_stack+0x40/0x50
[83159.038731]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
[83159.038732]  [8121bab8] ? btrfs_destroy_inode+0x278/0x2a0
[83159.038735]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
[83159.038737]  [81083974] ? task_work_run+0xb4/0x100
[83159.038740]  [8103b9a9] ? do_notify_resume+0x69/0x80
[83159.038742]  [81694092] ? system_call_fastpath+0x12/0x17
[83159.038743] ---[ end trace 3b7c45c6e46fe8dd ]---
[83159.038744] [ cut here ]
[83159.038745] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8694 
btrfs_destroy_inode+0x1f2/0x2a0()
[83159.038746] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
4.0.0-rc1-dirty #104
[83159.038747] Hardware name: System manufacturer System Product 
Name/M4A78T-E, BIOS 350304/13/2011
[83159.038747]   810f 8168d723 

[83159.038749]  8106d2d2  88005756edf0 
880215805800
[83159.038750]  880169477eb8 88005756edf0 8121ba32 
880100675000
[83159.038751] Call Trace:
[83159.038753]  [8168d723] ? dump_stack+0x40/0x50
[83159.038754]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
[83159.038755]  [8121ba32] ? btrfs_destroy_inode+0x1f2/0x2a0
[83159.038757]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
[83159.038758]  [81083974] ? task_work_run+0xb4/0x100
[83159.038760]  [8103b9a9] ? do_notify_resume+0x69/0x80
[83159.038761]  [81694092] ? system_call_fastpath+0x12/0x17
[83159.038762] ---[ end trace 3b7c45c6e46fe8de ]---
   
Unfortunately the issue isn't 100% reproducible, so I unfortunately
cannot bisect.
  
   You probably don't need to bisect. The warning is related to the
   outstanding_extents counter being != 0:
  
   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/inode.c?id=refs/tags/v4.0-rc1#n8693
  
   The only change in 4.0 that changes updates to that counter is:
  
   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e05bde8c3c2dd761da4d52944a087907955a53c
  
   So that's likely the change you would find with a bisect.
 
  OK, thank you. I will revert the commit and see if it fixes the issue.
 
  No. Reverting 3e05bde8c3 does _not_ fix the issue. It still happens.
 
 Ok, so I ran into this as well, and identified the following patch as
 the source of the problem:
 
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dcab6a3b2ae657a2017637083c28ee303b6b1b8e
 
 It's actually very easy to trigger. The following fio job config triggers it:
 
 [global]
 ioengine=sync
 direct=0
 bssplit=130M/100
 fallocate=none
 filename=foobar
 
 [job1]
 numjobs=1
 size=1G
 rw=randwrite
 
 Then run these steps:
 
 mkfs.btrfs -f /dev/sdd
 mount /dev/sdd /mnt
 cd /mnt
 fio fio_job.ini
 cd ..
 umount /mnt
 (see dmesg)
 
 The important part is that the writes need to be larger than 128Mb.
 With btrfs assertions enabled (CONFIG_BTRFS_ASSERT=y) you'll get a
 BUG_ON() immediately:
 
 [211158.63] BTRFS: assertion failed:
 BTRFS_I(inode)-outstanding_extents = num_extents, file:
 fs/btrfs/extent-tree.c, line: 4983
 [211158.557901] [ cut here ]
 [211158.558666] kernel BUG at fs/btrfs/ctree.h:4013!
 [211158.559660] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC
 ()
 [211158.561837] Call Trace:
 [211158.561837]  [a0474666] drop_outstanding_extent+0x3d/0x6d 
 [btrfs]
 [211158.561837]  [a047a5b8]
 btrfs_delalloc_release_metadata+0x53/0xfc [btrfs]
 ()
 
 Otherwise only the warnings you reported during inode eviction.
 
 This happens for both direct IO and buffered writes (direct=0). At
 least for the direct IO case, the issue happens due to underflows when
 decrementing the inode's outstanding_extents counter (after the very
 first write we get

Re: WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()

2015-03-03 Thread Markus Trippelsdorf 
On 2015.03.02 at 14:29 +0100, Markus Trippelsdorf wrote:
 On 2015.03.02 at 12:07 +, Filipe David Manana wrote:
   [83159.038708] [ cut here ]
   [83159.038716] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 
   btrfs_destroy_inode+0x278/0x2a0()
   [83159.038718] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
   4.0.0-rc1-dirty #104
   [83159.038719] Hardware name: System manufacturer System Product 
   Name/M4A78T-E, BIOS 350304/13/2011
   [83159.038720]   810f 8168d723 
   
   [83159.038722]  8106d2d2  88005756edf0 
   880215805800
   [83159.038723]  880169477eb8 88005756edf0 8121bab8 
   880100675000
   [83159.038725] Call Trace:
   [83159.038728]  [8168d723] ? dump_stack+0x40/0x50
   [83159.038731]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
   [83159.038732]  [8121bab8] ? btrfs_destroy_inode+0x278/0x2a0
   [83159.038735]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
   [83159.038737]  [81083974] ? task_work_run+0xb4/0x100
   [83159.038740]  [8103b9a9] ? do_notify_resume+0x69/0x80
   [83159.038742]  [81694092] ? system_call_fastpath+0x12/0x17
   [83159.038743] ---[ end trace 3b7c45c6e46fe8dd ]---
   [83159.038744] [ cut here ]
   [83159.038745] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8694 
   btrfs_destroy_inode+0x1f2/0x2a0()
   [83159.038746] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
   4.0.0-rc1-dirty #104
   [83159.038747] Hardware name: System manufacturer System Product 
   Name/M4A78T-E, BIOS 350304/13/2011
   [83159.038747]   810f 8168d723 
   
   [83159.038749]  8106d2d2  88005756edf0 
   880215805800
   [83159.038750]  880169477eb8 88005756edf0 8121ba32 
   880100675000
   [83159.038751] Call Trace:
   [83159.038753]  [8168d723] ? dump_stack+0x40/0x50
   [83159.038754]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
   [83159.038755]  [8121ba32] ? btrfs_destroy_inode+0x1f2/0x2a0
   [83159.038757]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
   [83159.038758]  [81083974] ? task_work_run+0xb4/0x100
   [83159.038760]  [8103b9a9] ? do_notify_resume+0x69/0x80
   [83159.038761]  [81694092] ? system_call_fastpath+0x12/0x17
   [83159.038762] ---[ end trace 3b7c45c6e46fe8de ]---
  
   Unfortunately the issue isn't 100% reproducible, so I unfortunately
   cannot bisect.
  
  You probably don't need to bisect. The warning is related to the
  outstanding_extents counter being != 0:
  
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/inode.c?id=refs/tags/v4.0-rc1#n8693
  
  The only change in 4.0 that changes updates to that counter is:
  
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e05bde8c3c2dd761da4d52944a087907955a53c
  
  So that's likely the change you would find with a bisect.
 
 OK, thank you. I will revert the commit and see if it fixes the issue.

No. Reverting 3e05bde8c3 does _not_ fix the issue. It still happens.

-- 
Markus
--
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: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()

2015-03-02 Thread Markus Trippelsdorf 
On 2015.02.24 at 13:29 +0100, Markus Trippelsdorf wrote:
 On 2015.02.20 at 11:09 +0100, Markus Trippelsdorf wrote:
  
  I get the following warnings during Firefox LTO build. lto1-wpa-stream
  outputs the final object files in parallel and therefore stresses the
  filessystem.
  These warnings started with the git merge above.
  
  The disk is a conventional drive:
  
  [2.438132] scsi 1:0:0:0: Direct-Access ATA  ST2000DM001-1CH1 
  CC29 PQ: 0 ANSI: 5
  [2.438308] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
  TB/1.81 TiB)
  [2.438310] sd 1:0:0:0: [sda] 4096-byte physical blocks
  
  /dev/sda2  btrfs 1.9T  905G  946G  49% /var
  /dev/sda2 on /var type btrfs (rw,relatime,compress=lzo,noacl,space_cache)
  
  
  [ 4155.708579] [ cut here ]
  [ 4155.708590] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8693 
  btrfs_destroy_inode+0x278/0x2a0()
  [ 4155.708593] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Not tainted 
  3.19.0-08975-g3d883483dc0a-dirty #101
  [ 4155.708594] Hardware name: System manufacturer System Product 
  Name/M4A78T-E, BIOS 350304/13/2011
  [ 4155.708595]   81999aad 8168d303 
  
  [ 4155.708597]  8106d2d2 8800dad9bb78 88018554ccc0 
  880215e2e000
  [ 4155.708599]  880215f23000  8121b6f8 
  
  [ 4155.708601] Call Trace:
  [ 4155.708606]  [8168d303] ? dump_stack+0x40/0x50
  [ 4155.708609]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
  [ 4155.708611]  [8121b6f8] ? btrfs_destroy_inode+0x278/0x2a0
  [ 4155.708614]  [81129381] ? dispose_list+0x41/0x60
  [ 4155.708615]  [81129669] ? prune_icache_sb+0x49/0x60
  [ 4155.708618]  [8111205a] ? super_cache_scan+0x13a/0x1a0
  [ 4155.708621]  [810e0a1b] ? 
  shrink_slab.part.52.constprop.62+0x19b/0x240
  [ 4155.708623]  [810e3049] ? shrink_zone+0x89/0xa0
  [ 4155.708625]  [810e3241] ? try_to_free_pages+0x1e1/0x320
  [ 4155.708626]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
  [ 4155.708629]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
  [ 4155.708631]  [81092e15] ? put_prev_task_fair+0x75/0x320
  [ 4155.708632]  [810903b0] ? __dequeue_entity+0x30/0x40
  [ 4155.708633]  [81094975] ? pick_next_task_fair+0x415/0x480
  [ 4155.708636]  [81064144] ? __do_page_fault+0x104/0x3a0
  [ 4155.708637]  [8168fb77] ? __schedule+0x257/0x860
  [ 4155.708639]  [8169518f] ? page_fault+0x1f/0x30
  [ 4155.708640] ---[ end trace 265993ee076d84aa ]---
  [ 4155.708641] [ cut here ]
  [ 4155.708643] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8694 
  btrfs_destroy_inode+0x1f2/0x2a0()
  [ 4155.708644] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Tainted: GW   
  3.19.0-08975-g3d883483dc0a-dirty #101
  [ 4155.708645] Hardware name: System manufacturer System Product 
  Name/M4A78T-E, BIOS 350304/13/2011
  [ 4155.708645]   81999aad 8168d303 
  
  [ 4155.708647]  8106d2d2 8800dad9bb78 88018554ccc0 
  880215e2e000
  [ 4155.708648]  880215f23000  8121b672 
  
  [ 4155.708649] Call Trace:
  [ 4155.708651]  [8168d303] ? dump_stack+0x40/0x50
  [ 4155.708652]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
  [ 4155.708654]  [8121b672] ? btrfs_destroy_inode+0x1f2/0x2a0
  [ 4155.708655]  [81129381] ? dispose_list+0x41/0x60
  [ 4155.708656]  [81129669] ? prune_icache_sb+0x49/0x60
  [ 4155.708658]  [8111205a] ? super_cache_scan+0x13a/0x1a0
  [ 4155.708659]  [810e0a1b] ? 
  shrink_slab.part.52.constprop.62+0x19b/0x240
  [ 4155.708661]  [810e3049] ? shrink_zone+0x89/0xa0
  [ 4155.708662]  [810e3241] ? try_to_free_pages+0x1e1/0x320
  [ 4155.708664]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
  [ 4155.708665]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
  [ 4155.708667]  [81092e15] ? put_prev_task_fair+0x75/0x320
  [ 4155.708668]  [810903b0] ? __dequeue_entity+0x30/0x40
  [ 4155.708669]  [81094975] ? pick_next_task_fair+0x415/0x480
  [ 4155.708670]  [81064144] ? __do_page_fault+0x104/0x3a0
  [ 4155.708672]  [8168fb77] ? __schedule+0x257/0x860
  [ 4155.708673]  [8169518f] ? page_fault+0x1f/0x30
  [ 4155.708674] ---[ end trace 265993ee076d84ab ]---
  [ 4156.021127] [ cut here ]
  [ 4156.021136] WARNING: CPU: 3 PID: 35 at fs/btrfs/inode.c:8693 
  btrfs_destroy_inode+0x278/0x2a0()
  [ 4156.021139] CPU: 3 PID: 35 Comm: kswapd0 Tainted: GW   
  3.19.0-08975-g3d883483dc0a-dirty #101
  [ 4156.021140] Hardware name: System manufacturer System Product 
  Name/M4A78T-E, BIOS 350304/13/2011
  [ 4156.021141]   81999aad 8168d303

Re: WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()

2015-03-02 Thread Markus Trippelsdorf 
On 2015.03.02 at 12:07 +, Filipe David Manana wrote:
  [83159.038708] [ cut here ]
  [83159.038716] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 
  btrfs_destroy_inode+0x278/0x2a0()
  [83159.038718] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
  4.0.0-rc1-dirty #104
  [83159.038719] Hardware name: System manufacturer System Product 
  Name/M4A78T-E, BIOS 350304/13/2011
  [83159.038720]   810f 8168d723 
  
  [83159.038722]  8106d2d2  88005756edf0 
  880215805800
  [83159.038723]  880169477eb8 88005756edf0 8121bab8 
  880100675000
  [83159.038725] Call Trace:
  [83159.038728]  [8168d723] ? dump_stack+0x40/0x50
  [83159.038731]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
  [83159.038732]  [8121bab8] ? btrfs_destroy_inode+0x278/0x2a0
  [83159.038735]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
  [83159.038737]  [81083974] ? task_work_run+0xb4/0x100
  [83159.038740]  [8103b9a9] ? do_notify_resume+0x69/0x80
  [83159.038742]  [81694092] ? system_call_fastpath+0x12/0x17
  [83159.038743] ---[ end trace 3b7c45c6e46fe8dd ]---
  [83159.038744] [ cut here ]
  [83159.038745] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8694 
  btrfs_destroy_inode+0x1f2/0x2a0()
  [83159.038746] CPU: 2 PID: 32343 Comm: rm Tainted: GW   
  4.0.0-rc1-dirty #104
  [83159.038747] Hardware name: System manufacturer System Product 
  Name/M4A78T-E, BIOS 350304/13/2011
  [83159.038747]   810f 8168d723 
  
  [83159.038749]  8106d2d2  88005756edf0 
  880215805800
  [83159.038750]  880169477eb8 88005756edf0 8121ba32 
  880100675000
  [83159.038751] Call Trace:
  [83159.038753]  [8168d723] ? dump_stack+0x40/0x50
  [83159.038754]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
  [83159.038755]  [8121ba32] ? btrfs_destroy_inode+0x1f2/0x2a0
  [83159.038757]  [8111f747] ? do_unlinkat+0x1a7/0x2e0
  [83159.038758]  [81083974] ? task_work_run+0xb4/0x100
  [83159.038760]  [8103b9a9] ? do_notify_resume+0x69/0x80
  [83159.038761]  [81694092] ? system_call_fastpath+0x12/0x17
  [83159.038762] ---[ end trace 3b7c45c6e46fe8de ]---
 
  Unfortunately the issue isn't 100% reproducible, so I unfortunately
  cannot bisect.
 
 You probably don't need to bisect. The warning is related to the
 outstanding_extents counter being != 0:
 
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/inode.c?id=refs/tags/v4.0-rc1#n8693
 
 The only change in 4.0 that changes updates to that counter is:
 
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e05bde8c3c2dd761da4d52944a087907955a53c
 
 So that's likely the change you would find with a bisect.

OK, thank you. I will revert the commit and see if it fixes the issue.

-- 
Markus
--
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: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()

2015-02-24 Thread Markus Trippelsdorf 
On 2015.02.20 at 11:09 +0100, Markus Trippelsdorf wrote:
 
 I get the following warnings during Firefox LTO build. lto1-wpa-stream
 outputs the final object files in parallel and therefore stresses the
 filessystem.
 These warnings started with the git merge above.
 
 The disk is a conventional drive:
 
 [2.438132] scsi 1:0:0:0: Direct-Access ATA  ST2000DM001-1CH1 CC29 
 PQ: 0 ANSI: 5
 [2.438308] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
 TB/1.81 TiB)
 [2.438310] sd 1:0:0:0: [sda] 4096-byte physical blocks
 
 /dev/sda2  btrfs 1.9T  905G  946G  49% /var
 /dev/sda2 on /var type btrfs (rw,relatime,compress=lzo,noacl,space_cache)
 
 
 [ 4155.708579] [ cut here ]
 [ 4155.708590] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8693 
 btrfs_destroy_inode+0x278/0x2a0()
 [ 4155.708593] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Not tainted 
 3.19.0-08975-g3d883483dc0a-dirty #101
 [ 4155.708594] Hardware name: System manufacturer System Product 
 Name/M4A78T-E, BIOS 350304/13/2011
 [ 4155.708595]   81999aad 8168d303 
 
 [ 4155.708597]  8106d2d2 8800dad9bb78 88018554ccc0 
 880215e2e000
 [ 4155.708599]  880215f23000  8121b6f8 
 
 [ 4155.708601] Call Trace:
 [ 4155.708606]  [8168d303] ? dump_stack+0x40/0x50
 [ 4155.708609]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
 [ 4155.708611]  [8121b6f8] ? btrfs_destroy_inode+0x278/0x2a0
 [ 4155.708614]  [81129381] ? dispose_list+0x41/0x60
 [ 4155.708615]  [81129669] ? prune_icache_sb+0x49/0x60
 [ 4155.708618]  [8111205a] ? super_cache_scan+0x13a/0x1a0
 [ 4155.708621]  [810e0a1b] ? 
 shrink_slab.part.52.constprop.62+0x19b/0x240
 [ 4155.708623]  [810e3049] ? shrink_zone+0x89/0xa0
 [ 4155.708625]  [810e3241] ? try_to_free_pages+0x1e1/0x320
 [ 4155.708626]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
 [ 4155.708629]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
 [ 4155.708631]  [81092e15] ? put_prev_task_fair+0x75/0x320
 [ 4155.708632]  [810903b0] ? __dequeue_entity+0x30/0x40
 [ 4155.708633]  [81094975] ? pick_next_task_fair+0x415/0x480
 [ 4155.708636]  [81064144] ? __do_page_fault+0x104/0x3a0
 [ 4155.708637]  [8168fb77] ? __schedule+0x257/0x860
 [ 4155.708639]  [8169518f] ? page_fault+0x1f/0x30
 [ 4155.708640] ---[ end trace 265993ee076d84aa ]---
 [ 4155.708641] [ cut here ]
 [ 4155.708643] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8694 
 btrfs_destroy_inode+0x1f2/0x2a0()
 [ 4155.708644] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Tainted: GW 
   3.19.0-08975-g3d883483dc0a-dirty #101
 [ 4155.708645] Hardware name: System manufacturer System Product 
 Name/M4A78T-E, BIOS 350304/13/2011
 [ 4155.708645]   81999aad 8168d303 
 
 [ 4155.708647]  8106d2d2 8800dad9bb78 88018554ccc0 
 880215e2e000
 [ 4155.708648]  880215f23000  8121b672 
 
 [ 4155.708649] Call Trace:
 [ 4155.708651]  [8168d303] ? dump_stack+0x40/0x50
 [ 4155.708652]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
 [ 4155.708654]  [8121b672] ? btrfs_destroy_inode+0x1f2/0x2a0
 [ 4155.708655]  [81129381] ? dispose_list+0x41/0x60
 [ 4155.708656]  [81129669] ? prune_icache_sb+0x49/0x60
 [ 4155.708658]  [8111205a] ? super_cache_scan+0x13a/0x1a0
 [ 4155.708659]  [810e0a1b] ? 
 shrink_slab.part.52.constprop.62+0x19b/0x240
 [ 4155.708661]  [810e3049] ? shrink_zone+0x89/0xa0
 [ 4155.708662]  [810e3241] ? try_to_free_pages+0x1e1/0x320
 [ 4155.708664]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
 [ 4155.708665]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
 [ 4155.708667]  [81092e15] ? put_prev_task_fair+0x75/0x320
 [ 4155.708668]  [810903b0] ? __dequeue_entity+0x30/0x40
 [ 4155.708669]  [81094975] ? pick_next_task_fair+0x415/0x480
 [ 4155.708670]  [81064144] ? __do_page_fault+0x104/0x3a0
 [ 4155.708672]  [8168fb77] ? __schedule+0x257/0x860
 [ 4155.708673]  [8169518f] ? page_fault+0x1f/0x30
 [ 4155.708674] ---[ end trace 265993ee076d84ab ]---
 [ 4156.021127] [ cut here ]
 [ 4156.021136] WARNING: CPU: 3 PID: 35 at fs/btrfs/inode.c:8693 
 btrfs_destroy_inode+0x278/0x2a0()
 [ 4156.021139] CPU: 3 PID: 35 Comm: kswapd0 Tainted: GW   
 3.19.0-08975-g3d883483dc0a-dirty #101
 [ 4156.021140] Hardware name: System manufacturer System Product 
 Name/M4A78T-E, BIOS 350304/13/2011
 [ 4156.021141]   81999aad 8168d303 
 
 [ 4156.021143]  8106d2d2 8802160dfcb8 88006b07a690 
 880215e2e000
 [ 4156.021145]  880215f23000  8121b6f8

Re: [GIT PULL] Btrfs

2015-02-20 Thread Markus Trippelsdorf 
On 2015.02.19 at 15:36 -0500, Chris Mason wrote:
 Hi Linus,
 
 Please pull my for-linus branch:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

I get the following warnings during Firefox LTO build. lto1-wpa-stream
outputs the final object files in parallel and therefore stresses the
filessystem.
These warnings started with the git merge above.

The disk is a conventional drive:

[2.438132] scsi 1:0:0:0: Direct-Access ATA  ST2000DM001-1CH1 CC29 
PQ: 0 ANSI: 5
[2.438308] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
TB/1.81 TiB)
[2.438310] sd 1:0:0:0: [sda] 4096-byte physical blocks

/dev/sda2  btrfs 1.9T  905G  946G  49% /var
/dev/sda2 on /var type btrfs (rw,relatime,compress=lzo,noacl,space_cache)


[ 4155.708579] [ cut here ]
[ 4155.708590] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8693 
btrfs_destroy_inode+0x278/0x2a0()
[ 4155.708593] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Not tainted 
3.19.0-08975-g3d883483dc0a-dirty #101
[ 4155.708594] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[ 4155.708595]   81999aad 8168d303 

[ 4155.708597]  8106d2d2 8800dad9bb78 88018554ccc0 
880215e2e000
[ 4155.708599]  880215f23000  8121b6f8 

[ 4155.708601] Call Trace:
[ 4155.708606]  [8168d303] ? dump_stack+0x40/0x50
[ 4155.708609]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
[ 4155.708611]  [8121b6f8] ? btrfs_destroy_inode+0x278/0x2a0
[ 4155.708614]  [81129381] ? dispose_list+0x41/0x60
[ 4155.708615]  [81129669] ? prune_icache_sb+0x49/0x60
[ 4155.708618]  [8111205a] ? super_cache_scan+0x13a/0x1a0
[ 4155.708621]  [810e0a1b] ? 
shrink_slab.part.52.constprop.62+0x19b/0x240
[ 4155.708623]  [810e3049] ? shrink_zone+0x89/0xa0
[ 4155.708625]  [810e3241] ? try_to_free_pages+0x1e1/0x320
[ 4155.708626]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
[ 4155.708629]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
[ 4155.708631]  [81092e15] ? put_prev_task_fair+0x75/0x320
[ 4155.708632]  [810903b0] ? __dequeue_entity+0x30/0x40
[ 4155.708633]  [81094975] ? pick_next_task_fair+0x415/0x480
[ 4155.708636]  [81064144] ? __do_page_fault+0x104/0x3a0
[ 4155.708637]  [8168fb77] ? __schedule+0x257/0x860
[ 4155.708639]  [8169518f] ? page_fault+0x1f/0x30
[ 4155.708640] ---[ end trace 265993ee076d84aa ]---
[ 4155.708641] [ cut here ]
[ 4155.708643] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8694 
btrfs_destroy_inode+0x1f2/0x2a0()
[ 4155.708644] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Tainted: GW   
3.19.0-08975-g3d883483dc0a-dirty #101
[ 4155.708645] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[ 4155.708645]   81999aad 8168d303 

[ 4155.708647]  8106d2d2 8800dad9bb78 88018554ccc0 
880215e2e000
[ 4155.708648]  880215f23000  8121b672 

[ 4155.708649] Call Trace:
[ 4155.708651]  [8168d303] ? dump_stack+0x40/0x50
[ 4155.708652]  [8106d2d2] ? warn_slowpath_common+0x72/0xc0
[ 4155.708654]  [8121b672] ? btrfs_destroy_inode+0x1f2/0x2a0
[ 4155.708655]  [81129381] ? dispose_list+0x41/0x60
[ 4155.708656]  [81129669] ? prune_icache_sb+0x49/0x60
[ 4155.708658]  [8111205a] ? super_cache_scan+0x13a/0x1a0
[ 4155.708659]  [810e0a1b] ? 
shrink_slab.part.52.constprop.62+0x19b/0x240
[ 4155.708661]  [810e3049] ? shrink_zone+0x89/0xa0
[ 4155.708662]  [810e3241] ? try_to_free_pages+0x1e1/0x320
[ 4155.708664]  [810daa82] ? __alloc_pages_nodemask+0x382/0x680
[ 4155.708665]  [810f597d] ? handle_mm_fault+0xbbd/0xe60
[ 4155.708667]  [81092e15] ? put_prev_task_fair+0x75/0x320
[ 4155.708668]  [810903b0] ? __dequeue_entity+0x30/0x40
[ 4155.708669]  [81094975] ? pick_next_task_fair+0x415/0x480
[ 4155.708670]  [81064144] ? __do_page_fault+0x104/0x3a0
[ 4155.708672]  [8168fb77] ? __schedule+0x257/0x860
[ 4155.708673]  [8169518f] ? page_fault+0x1f/0x30
[ 4155.708674] ---[ end trace 265993ee076d84ab ]---
[ 4156.021127] [ cut here ]
[ 4156.021136] WARNING: CPU: 3 PID: 35 at fs/btrfs/inode.c:8693 
btrfs_destroy_inode+0x278/0x2a0()
[ 4156.021139] CPU: 3 PID: 35 Comm: kswapd0 Tainted: GW   
3.19.0-08975-g3d883483dc0a-dirty #101
[ 4156.021140] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[ 4156.021141]   81999aad 8168d303 

[ 4156.021143]  8106d2d2 8802160dfcb8 88006b07a690 
880215e2e000
[ 4156.021145]  880215f23000

WARNING: at fs/btrfs/extent_map.c:226 unpin_extent_cache+0x4b/0xa0()

2012-06-01 Thread Markus Trippelsdorf 
I'm running the latest git kernel with the btrfs updates already merged.
Today I've hit the following warnings during rsnapshot backup:

Jun  1 22:26:30 x4 kernel: Adding 1953788k swap on /dev/sda2.  Priority:-1 
extents:1 across:1953788k 
Jun  2 01:52:30 x4 kernel: [ cut here ]
Jun  2 01:52:30 x4 kernel: WARNING: at fs/btrfs/extent_map.c:226 
unpin_extent_cache+0x4b/0xa0()
Jun  2 01:52:30 x4 kernel: Hardware name: System Product Name
Jun  2 01:52:30 x4 kernel: Pid: 24991, comm: btrfs-endio-wri Not tainted 
3.4.0-09820-g86c47b7-dirty #50
Jun  2 01:52:30 x4 kernel: Call Trace:
Jun  2 01:52:30 x4 kernel: [8105c6c0] ? warn_slowpath_common+0x60/0xa0
Jun  2 01:52:30 x4 kernel: [8121d6eb] ? unpin_extent_cache+0x4b/0xa0
Jun  2 01:52:30 x4 kernel: [8121207e] ? 
btrfs_finish_ordered_io+0x27e/0x400
Jun  2 01:52:30 x4 kernel: [8123bb02] ? worker_loop+0x142/0x4c0
Jun  2 01:52:30 x4 kernel: [8123b9c0] ? btrfs_queue_worker+0x300/0x300
Jun  2 01:52:30 x4 kernel: [81077ae5] ? kthread+0x85/0xa0
Jun  2 01:52:30 x4 kernel: [81561c54] ? kernel_thread_helper+0x4/0x10
Jun  2 01:52:30 x4 kernel: [81077a60] ? 
kthread_flush_work_fn+0x20/0x20
Jun  2 01:52:30 x4 kernel: [81561c50] ? gs_change+0xb/0xb
Jun  2 01:52:30 x4 kernel: ---[ end trace 73bddc9623dbf3c3 ]---
...
Jun  2 01:55:27 x4 kernel: [ cut here ]
Jun  2 01:55:27 x4 kernel: WARNING: at fs/btrfs/extent_map.c:226 
unpin_extent_cache+0x4b/0xa0()
Jun  2 01:55:27 x4 kernel: Hardware name: System Product Name
Jun  2 01:55:27 x4 kernel: Pid: 24997, comm: btrfs-endio-wri Tainted: G
W3.4.0-09820-g86c47b7-dirty #50
Jun  2 01:55:27 x4 kernel: Call Trace:
Jun  2 01:55:27 x4 kernel: [8105c6c0] ? warn_slowpath_common+0x60/0xa0
Jun  2 01:55:27 x4 kernel: [8121d6eb] ? unpin_extent_cache+0x4b/0xa0
Jun  2 01:55:27 x4 kernel: [8121207e] ? 
btrfs_finish_ordered_io+0x27e/0x400
Jun  2 01:55:27 x4 kernel: [8123bb02] ? worker_loop+0x142/0x4c0
Jun  2 01:55:27 x4 kernel: [8123b9c0] ? btrfs_queue_worker+0x300/0x300
Jun  2 01:55:27 x4 kernel: [81077ae5] ? kthread+0x85/0xa0
Jun  2 01:55:27 x4 kernel: [81561c54] ? kernel_thread_helper+0x4/0x10
Jun  2 01:55:27 x4 kernel: [81077a60] ? 
kthread_flush_work_fn+0x20/0x20
Jun  2 01:55:27 x4 kernel: [81561c50] ? gs_change+0xb/0xb
Jun  2 01:55:27 x4 kernel: ---[ end trace 73bddc9623dbf3eb ]---

 ~ #  /var/log/kern.log | grep extent_map | wc -l
41

From /var/log/cron.log

Jun  2 01:52:00 x4 fcron[24821]: Job /usr/bin/rsnapshot daily started for user 
root (pid 24822)
Jun  2 01:55:29 x4 fcron[24821]: Job /usr/bin/rsnapshot daily completed 
(mailing output)

 ~ # btrfs fi df /var
Data, RAID1: total=758.00GB, used=538.32GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=116.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=37.50GB, used=1.88GB
Metadata: total=8.00MB, used=0.00

~ # btrfs subvol list /var
ID 773 top level 5 path .snapshots/daily.0
ID 800 top level 5 path .snapshots/monthly.0
ID 811 top level 5 path .snapshots/weekly.3
ID 813 top level 5 path .snapshots/weekly.2
ID 839 top level 5 path .snapshots/weekly.1
ID 870 top level 5 path .snapshots/weekly.0
ID 871 top level 5 path .snapshots/daily.6
ID 872 top level 5 path .snapshots/daily.5
ID 873 top level 5 path .snapshots/daily.4
ID 874 top level 5 path .snapshots/daily.3
ID 875 top level 5 path .snapshots/daily.2
ID 876 top level 5 path .snapshots/daily.1

Rsnapshot creates a new snapshot with:
 btrfs subvolume snapshot -r
and then uses rsync to backup my root drive (on xfs).

-- 
Markus
--
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: at fs/btrfs/extent_map.c:226 unpin_extent_cache+0x4b/0xa0()

2012-06-01 Thread Markus Trippelsdorf 
On 2012.06.02 at 04:10 +0200, Markus Trippelsdorf wrote:
 I'm running the latest git kernel with the btrfs updates already merged.
 Today I've hit the following warnings during rsnapshot backup:
 
 Jun  1 22:26:30 x4 kernel: Adding 1953788k swap on /dev/sda2.  Priority:-1 
 extents:1 across:1953788k 
 Jun  2 01:52:30 x4 kernel: [ cut here ]
 Jun  2 01:52:30 x4 kernel: WARNING: at fs/btrfs/extent_map.c:226 
 unpin_extent_cache+0x4b/0xa0()

 # btrfsck /dev/sdb1
failed to read /dev/sr0: No medium found
failed to read /dev/sr0: No medium found
root 773 inode 2315 errors 400
root 773 inode 16035 errors 1000
root 773 inode 23441 errors 1000
root 773 inode 23487 errors 400
root 773 inode 23888 errors 400
root 773 inode 27513 errors 1000
root 773 inode 103998 errors 1000
root 773 inode 110549 errors 400
root 773 inode 110922 errors 400
root 773 inode 111092 errors 400
root 773 inode 111204 errors 400
root 773 inode 238989 errors 400
root 773 inode 239005 errors 400
root 773 inode 239006 errors 400
root 773 inode 239007 errors 400
root 773 inode 239155 errors 400
root 773 inode 239238 errors 400
root 773 inode 241169 errors 400
root 773 inode 247072 errors 400
root 773 inode 247076 errors 400
root 773 inode 247078 errors 400
root 773 inode 247079 errors 400
root 773 inode 247082 errors 400
root 773 inode 247084 errors 400
root 773 inode 247085 errors 400
root 773 inode 247086 errors 400
root 773 inode 247087 errors 400
root 773 inode 247088 errors 400
root 773 inode 247092 errors 400
root 773 inode 247094 errors 400
root 773 inode 247096 errors 400
root 773 inode 247099 errors 400
root 773 inode 249924 errors 400
root 773 inode 272199 errors 1000
root 773 inode 274836 errors 400
root 773 inode 275402 errors 400
root 773 inode 279188 errors 400
root 773 inode 279454 errors 400
root 773 inode 279473 errors 400
root 773 inode 280002 errors 1000
root 773 inode 280378 errors 400
root 773 inode 280425 errors 400
root 773 inode 280517 errors 400
root 773 inode 280598 errors 1000
root 773 inode 280721 errors 400
root 773 inode 280828 errors 1000
root 773 inode 281135 errors 400
root 773 inode 281587 errors 400
root 773 inode 282019 errors 400
root 773 inode 282534 errors 1000
root 773 inode 283008 errors 400
root 773 inode 283052 errors 400
root 773 inode 283644 errors 400
root 773 inode 284382 errors 400
root 773 inode 284755 errors 400
root 773 inode 284792 errors 400
root 773 inode 285630 errors 400
root 773 inode 285846 errors 400
root 773 inode 286754 errors 400
root 773 inode 287473 errors 400
root 773 inode 287474 errors 400
root 773 inode 288128 errors 400
root 773 inode 288894 errors 400
root 773 inode 289555 errors 400
root 773 inode 289594 errors 400
root 773 inode 290633 errors 1000
root 773 inode 290886 errors 400
root 773 inode 291418 errors 1000
root 773 inode 291643 errors 1000
root 773 inode 292149 errors 1000
root 773 inode 292654 errors 1000
root 773 inode 304425 errors 400
root 773 inode 306969 errors 1000
root 773 inode 307251 errors 1000
root 773 inode 307254 errors 1000
root 773 inode 307558 errors 400
root 773 inode 307591 errors 400
root 773 inode 308160 errors 400
root 773 inode 308870 errors 400
root 773 inode 308880 errors 1000
root 773 inode 309013 errors 400
root 773 inode 309323 errors 400
root 773 inode 309543 errors 400
root 773 inode 310070 errors 400
root 773 inode 310106 errors 400
root 773 inode 311893 errors 400
root 773 inode 312734 errors 1000
root 773 inode 312736 errors 1000
root 773 inode 313624 errors 400
root 773 inode 313629 errors 400
root 773 inode 313630 errors 400
root 773 inode 314326 errors 1000
root 773 inode 314516 errors 400
root 773 inode 314705 errors 400
root 773 inode 315962 errors 1000
root 773 inode 316073 errors 400
root 773 inode 316323 errors 1000
root 773 inode 316324 errors 1000
root 773 inode 318054 errors 1000
root 773 inode 318932 errors 1000
root 773 inode 319048 errors 1000
root 773 inode 323024 errors 1000
root 773 inode 323183 errors 1000
root 773 inode 323193 errors 1000
root 773 inode 323227 errors 1000
root 773 inode 323624 errors 1000
root 773 inode 323642 errors 1000
root 773 inode 323841 errors 1000
root 773 inode 324579 errors 400
root 773 inode 324806 errors 1000
root 773 inode 335590 errors 1000
root 773 inode 335985 errors 400
root 773 inode 336118 errors 1000
root 773 inode 336173 errors 1000
root 773 inode 338188 errors 1000
root 773 inode 338799 errors 1000
root 773 inode 338839 errors 1000
root 773 inode 347565 errors 400
root 773 inode 347570 errors 400
root 773 inode 347573 errors 400
root 773 inode 347579 errors 400
root 773 inode 347702 errors 1000
found 580033277952 bytes used err is 1
total csum bytes: 562329788
total tree bytes: 2014085120
total fs tree bytes: 1084829696
btree space waste bytes: 429308389
file data blocks allocated: 7079238537216
 referenced 51031168
Btrfs Btrfs v0.19

-- 
Markus
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord

Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags

2011-04-22 Thread Markus Trippelsdorf 
On 2011.04.22 at 00:50 -0400, Christoph Hellwig wrote:
 [Eric: please don't drop the Cc list, thanks!]
 
 On Thu, Apr 21, 2011 at 09:22:55PM -0400, Josef Bacik wrote:
   since all files have a virtual hole at the end, but leaves the position
   unchanged). ??I'd have to write a test program on Solaris to see whether 
   that
   definition is actually true, or if it is a bug in the Solaris man page.
  
  
  lseek's purpose is to reposition the file position, so I'd imagine
  this is just a bug in the man page.
 
 I would be surprised if the bug is around for such a long time, but
 otherwise I concur.

It's a bug. Let me quote what Jeff Bonwick wrote on his blog:

»I'm not sure where you got the impression that either SEEK_HOLE or
SEEK_DATA doesn't set the file pointer. They do. (If they didn't, that
would be weird, and we'd call it out explicitly.)«

http://blogs.sun.com/bonwick/entry/seek_hole_and_seek_data

-- 
Markus
--
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 allocation failed while running qemu image

2010-12-25 Thread Markus Trippelsdorf 
Just got these errors on a btrfs test partion, when I started qemu with
a qcow2 image file (freshly copied from a ext4 partition shortly before):

 % qemu-kvm -net nic,vlan=0,model=virtio -net user -drive 
file=ubuntu,if=virtio,boot=on -smp 2 -m 512

Dec 25 17:58:41 [kernel] btrfs allocation failed flags 36, wanted 4096
Dec 25 17:58:41 [kernel] space_info has 221898240 free, is not full
Dec 25 17:58:41 [kernel] space_info total=1350565888, used=633548800, 
pinned=262320128, reserved=224344576, may_use=0, readonly=8454144
Dec 25 17:58:41 [kernel] block group 29360128 has 1073741824 bytes, 633032704 
used 8192 pinned 4587520 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 395166351360 has 134217728 bytes, 471040 
used 133709824 pinned 36864 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 462946304000 has 134217728 bytes, 45056 
used 128602112 pinned 5570560 reserved
Dec 25 17:58:41 [kernel] entry offset 462946304000, bytes 0, bitmap yes
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 4194304 has 8388608 bytes, 0 used 0 pinned 
0 reserved
Dec 25 17:58:41 [kernel] entry offset 4194304, bytes 8388608, bitmap no
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 1 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] btrfs allocation failed flags 36, wanted 4096
Dec 25 17:58:41 [kernel] space_info has 221902336 free, is not full
Dec 25 17:58:41 [kernel] space_info total=1350565888, used=633548800, 
pinned=262320128, reserved=224340480, may_use=0, readonly=8454144
Dec 25 17:58:41 [kernel] block group 29360128 has 1073741824 bytes, 633032704 
used 8192 pinned 4587520 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 395166351360 has 134217728 bytes, 471040 
used 133709824 pinned 36864 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 462946304000 has 134217728 bytes, 45056 
used 128602112 pinned 5570560 reserved
Dec 25 17:58:41 [kernel] entry offset 462946304000, bytes 0, bitmap yes
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 4194304 has 8388608 bytes, 0 used 0 pinned 
0 reserved
Dec 25 17:58:41 [kernel] entry offset 4194304, bytes 8388608, bitmap no
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 1 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] kernel BUG at fs/btrfs/extent-tree.c:5420!
Dec 25 17:58:41 [kernel] btrfs allocation failed flags 36, wanted 4096
Dec 25 17:58:41 [kernel] space_info has 221911552 free, is not full
Dec 25 17:58:41 [kernel] space_info total=1350565888, used=633548800, 
pinned=262320128, reserved=224331264, may_use=0, readonly=8454144
Dec 25 17:58:41 [kernel] block group 29360128 has 1073741824 bytes, 633032704 
used 8192 pinned 4587520 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 395166351360 has 134217728 bytes, 471040 
used 133709824 pinned 36864 reserved
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 462946304000 has 134217728 bytes, 45056 
used 128602112 pinned 5570560 reserved
Dec 25 17:58:41 [kernel] entry offset 462946304000, bytes 0, bitmap yes
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 0 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] block group 4194304 has 8388608 bytes, 0 used 0 pinned 
0 reserved
Dec 25 17:58:41 [kernel] entry offset 4194304, bytes 8388608, bitmap no
Dec 25 17:58:41 [kernel] block group has cluster?: no
Dec 25 17:58:41 [kernel] 1 blocks of free space at or bigger than bytes is
Dec 25 17:58:41 [kernel] btrfs allocation failed flags 36, wanted 4096
- Last output repeated twice -
Dec 25 17:58:41 [kernel] space_info has 222006784 free, is not full
Dec 25 17:58:41 [kernel] space_info total=1350565888, used=633548800, 
pinned=262320128, reserved=224236032, may_use=0, readonly=8454144
Dec 25 17:58:41 [kernel] space_info has 222006784 free, is not full
Dec 25 17:58:41 [kernel] block group 29360128 has 1073741824 bytes, 633032704 
used 8192 pinned 4587520 reserved
Dec 25 17:58:41 [kernel] space_info total=1350565888,

btrfs failed to delete reference

2009-11-16 Thread Markus Trippelsdorf 
Last night the following line was logged:
Nov 16 04:01:07 arch kernel: btrfs failed to delete reference to ammintrin.h, 
inode 118665 parent 2687784

This file is part of an rsnapshot backup directory:
/var/.snapshots/hourly.5/localhost/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/install-tools/include

arch include # find . -inum 118665
find: `./ammintrin.h': No such file or directory

arch include # ls -al
ls: cannot access ammintrin.h: No such file or directory
total 0
drwxr-xr-x 1 root root 22 2009-11-16 08:39 .
drwxr-xr-x 1 root root 14 2009-11-16 04:01 ..
-? ? ?? ?? ammintrin.h

arch include # ..
arch install-tools # rm -fr include
rm: cannot remove directory `include': Directory not empty

How can I get rid of that file?

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-17 Thread Markus Trippelsdorf 
On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote:
 On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
  On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
   On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
Just got this error today in my dmesg:
btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 
43905798

linux % find . -inum 1483065
./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack

It's the main pack file from my git linux kernel tree:

   
   Hmm, I ran into something very similar. Care to check what the corrupted
   block of data looks like (and how big it is)?
  
  I've hit the same problem again today:
  
  btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 
  1660028275
  
  The file in question is:
  ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack
  
  I can't read the file directly, because of the csum mismatch:
 
 Chris, is there a way to force reading the file? Seems like that would
 be a very handy feature.
 
 Markus, not sure if that works, but you could always try and remount
 with data checksumming disabled.
 
 mount /dev/fooX -o remount,rw,nodatasum
 
 should do the trick.

That doesn't work unfortunately, btrfs still calculates and compares the
checksums (it won't write new ones I guess).

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-17 Thread Markus Trippelsdorf 
On Thu, Sep 17, 2009 at 11:05:49AM +0200, Jens Axboe wrote:
 On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
  On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote:
   On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
 On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
  Just got this error today in my dmesg:
  btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 
  43905798
  
  linux % find . -inum 1483065
  ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
  
  It's the main pack file from my git linux kernel tree:
  
 
 Hmm, I ran into something very similar. Care to check what the 
 corrupted
 block of data looks like (and how big it is)?

I've hit the same problem again today:

btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 
1660028275

The file in question is:
./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack

I can't read the file directly, because of the csum mismatch:
   
   Chris, is there a way to force reading the file? Seems like that would
   be a very handy feature.
   
   Markus, not sure if that works, but you could always try and remount
   with data checksumming disabled.
   
   mount /dev/fooX -o remount,rw,nodatasum
   
   should do the trick.
  
  That doesn't work unfortunately, btrfs still calculates and compares the
  checksums (it won't write new ones I guess).
 
 Ah ok, as mentioned I wasn't sure whether that would work or not. I'll
 defer to Chris :-)

Understood.

I did some further investigations and was able to reconstruct exactly
the same pack file in question by starting from an older backup copy of
my git repro and then running the same git commands as previous. 
Then I did a binary comparison between this reconstructed file and a
corrupted backup copy from the time before the csum errors occured (I
automatically backup every 4h).

This is the result (first line good pack file, second line corrupted
file):

vbindiff 
debug/.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack 
debug2/.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack

0130 9FA0: E2 3B 43 AA 63 BF 28 B3  87 B7 FD AB DA 74 2D 1C
0130 9FA0: E2 3B 43 AA 63 BF 28 B3  87 33 FD AB DA 74 2D 1C

06CD DF90: B0 22 6B 46 9F ED 6E 47  73 5E 7E EB DA 5F D6 11
06CD DF90: B0 22 6B 46 9F ED 6E 47  73 1E 7E EB DA 5F D6 11

06CD DFC0: 0D 86 2B B2 57 A4 5A CD  78 4B 08 94 C0 65 17 3A
06CD DFC0: 0D 86 2B B2 57 A4 5A CD  78 0B 08 94 C0 65 17 3A

0802 C3C0: 5C A5 E1 4A 1C BC 14 04  16 4A 29 D3 CC EF A6 80
0802 C3C0: 5C 25 E1 4A 1C BC 14 04  16 48 29 D3 CC EF A6 80

081A B3C0: 7D 7A 2C CD 20 89 E5 F2  A8 D3 32 38 04 BA 8A B5
081A B3C0: 7D 3A 2C CD 20 89 E5 F2  A8 D3 32 38 04 BA 8A B5

098E C430: FE 24 4A 19 09 F4 D5 1F  22 E8 36 FA F8 55 B2 6E
098E C430: FE 24 4A 19 09 F4 D5 1F  22 E0 36 FA F8 55 B2 6E

098E C440: 1B 3F C1 B4 BB 80 F8 5A  FB EE 0D A3 3F C5 A4 DB
098E C440: 1B 3D C1 B4 BB 80 F8 5A  FB EE 0D A3 3F C5 A4 DB

098E C4D0: F8 6C E2 65 18 7A 5D 33  2E 35 77 64 B2 81 BE DF
098E C4D0: F8 6C E2 65 18 7A 5D 33  2E 25 77 64 B2 81 BE DF

098E C4E0: 05 18 DE E3 00 78 D2 2C  4F 91 8F AF 0B F6 0C 31
098E C4E0: 05 1C DE E3 00 78 D2 2C  4F 91 8F AF 0B F6 0C 31

098E C500: 0A 12 D3 E7 FA B8 40 DE  0D 71 94 88 5D 4C 97 21
098E C500: 0A 12 D3 E7 FA B8 40 DE  0D 51 94 88 5D 4C 97 21

098E C540: 93 F2 58 C7 49 9A AA EB  30 3D 28 AA E3 09 4B 7B
098E C540: 93 F2 58 C7 49 9A AA EB  30 3C 28 AA E3 09 4B 7B

0FDE C420: F3 6A C2 38 76 43 9E 86  0D 9C 89 86 F1 E6 B0 F2
0FDE C420: F3 6A C2 38 76 43 9E 86  0D DC 89 86 F1 E6 B0 F2

0FDE C430: 38 E4 69 2E 22 1D E4 FF  90 A7 C6 E8 9F 08 4C 98
0FDE C430: 38 E4 69 2E 22 1D E4 FF  90 A5 C6 E8 9F 08 4C 98

1214 A4C0: 24 D6 56 AC 8B D8 D0 9B  D2 62 7B 83 C7 0B 3D BE
1214 A4C0: 24 D4 56 AC 8B D8 D0 9B  D2 62 7B 83 C7 0B 3D BE

1214 A500: EC 51 D3 FF C5 7D 30 DD  6D 45 50 FE E9 64 A4 FC
1214 A500: EC 11 D3 FF C5 7D 30 DD  6D 45 50 FE E9 64 A4 FC

1214 A520: D9 4D 63 EB 77 4D F0 BE  5E B3 6B DE E6 D2 28 67
1214 A520: D9 4D 63 EB 77 4D F0 BE  5E 33 6B DE E6 D2 28 67

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-17 Thread Markus Trippelsdorf 
On Thu, Sep 17, 2009 at 02:15:01PM +0200, Markus Trippelsdorf wrote:
 On Thu, Sep 17, 2009 at 11:05:49AM +0200, Jens Axboe wrote:
  On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
   On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote:
On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
 On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
  On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
   Just got this error today in my dmesg:
   btrfs csum failed ino 1483065 off 158482432 csum 4283543305 
   private 43905798
   
   linux % find . -inum 1483065
   ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
   
   It's the main pack file from my git linux kernel tree:
   
  
  Hmm, I ran into something very similar. Care to check what the 
  corrupted
  block of data looks like (and how big it is)?
 
 I've hit the same problem again today:
 
 btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 
 1660028275
 
 The file in question is:
 ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack
 
 I can't read the file directly, because of the csum mismatch:

Chris, is there a way to force reading the file? Seems like that would
be a very handy feature.

Markus, not sure if that works, but you could always try and remount
with data checksumming disabled.

mount /dev/fooX -o remount,rw,nodatasum

should do the trick.
   
   That doesn't work unfortunately, btrfs still calculates and compares the
   checksums (it won't write new ones I guess).
  
  Ah ok, as mentioned I wasn't sure whether that would work or not. I'll
  defer to Chris :-)
 
 Understood.
 
 I did some further investigations and was able to reconstruct exactly
 the same pack file in question by starting from an older backup copy of
 my git repro and then running the same git commands as previous. 
 Then I did a binary comparison between this reconstructed file and a
 corrupted backup copy from the time before the csum errors occured (I
 automatically backup every 4h).
 
Thanks to Chris' patch (from IRC) I was able to compare the file with
the csum error to the reconstructed one. You'll find the reults as
attachments.

-- 
Markus
08F403A0   5D 8E B3 32  7D 8F 5D E7  54 B6 9D 1E  E6 0C 9B 0D  BE 1D 9D 0C  34 
BA 7F FE  7F D4 E5 1A  0A 16 29 96
105AC3A0   76 80 1E 0A  3F 8A 7E FC  B3 2E 2B 9E  9E 53 82 10  C3 F6 4B C1  C0 
12 FC 61  A5 0E 63 70  B0 A4 7B 27
105AC3C0   DC AE 26 CE  48 5D CA 07  B7 26 B6 3C  BC 91 AD 00  55 97 BF E4  8C 
D7 EF AA  28 B7 54 65  30 DB 78 A6
105AC3E0   26 90 18 88  8F F4 25 91  48 5F 9C F6  4F 0D 46 72  A2 04 77 1A  AF 
FB 88 23  93 AF FB AA  B9 82 BC CC
08F403A0   5D 8E B3 32  7D 8F 5D E7  54 B4 9D 1E  E6 0C 9B 0D  BE 1D 9D 0C  34 
BA 7F FE  7F D4 E5 1A  0A 16 29 96
105AC3A0   76 80 1E 0A  3F 8A 7E FC  B3 2E 2B 9E  9E 53 82 10  C3 F7 4B C1  C0 
12 FC 61  A5 0E 63 70  B0 A4 7B 27
105AC3C0   DC AE 26 CE  48 5D CA 07  B7 77 B6 3C  BC 91 AD 00  55 97 BF E4  8C 
D7 EF AA  28 A7 54 65  30 DB 78 A6
105AC3E0   26 90 18 88  8F F4 25 91  48 5F 9C F6  4F 0D 46 72  A2 04 77 1A  AF 
FB 88 23  93 AF FB AA  B9 82 BC CC

Re: btrfs csum failed on git .pack file

2009-09-17 Thread Markus Trippelsdorf 
On Thu, Sep 17, 2009 at 10:00:28AM -0700, Zach Brown wrote:
 
  0130 9FA0: E2 3B 43 AA 63 BF 28 B3  87 B7 FD AB DA 74 2D 1C
  0130 9FA0: E2 3B 43 AA 63 BF 28 B3  87 33 FD AB DA 74 2D 1C
 
 B7 = 10110111
 33 = 00110011
 
  06CD DF90: B0 22 6B 46 9F ED 6E 47  73 5E 7E EB DA 5F D6 11
  06CD DF90: B0 22 6B 46 9F ED 6E 47  73 1E 7E EB DA 5F D6 11
 
 5E = 0100
 1E = 0000
 
  06CD DFC0: 0D 86 2B B2 57 A4 5A CD  78 4B 08 94 C0 65 17 3A
  06CD DFC0: 0D 86 2B B2 57 A4 5A CD  78 0B 08 94 C0 65 17 3A
 
 4B = 01001011
 0B = 1011
 
 And so on.
 
 It looks like a few bits are getting flipped at the same byte offset.
 One can imagine software bugs that would do this, certainly, but upset
 hardware seems awfully likely too.

I'm afraid you're right. I did some further tests and now I'm pretty
sure that a bad RAM module was the root cause of it all...
Oh well.

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-09 Thread Markus Trippelsdorf 
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
 On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
  On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
   On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
Just got this error today in my dmesg:
btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 
43905798

linux % find . -inum 1483065
./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack

It's the main pack file from my git linux kernel tree:

   
   Hmm, I ran into something very similar. Care to check what the corrupted
   block of data looks like (and how big it is)?
  
  I've already deleted the file in question unfortunately.
  On IRC Chris decided that either bad RAM or a harddrive error was the
  most likely reason for this chechsum mismatch.
 
 Darn, that's too bad. The corruption issue I had was also in a git pack
 file. It was fine one day, bad the next. Turned out to be 16kb of 0xff
 in the file, and I blamed it on the (cheap) SSD drive that hosted the
 local git repo. It's still the most likely explanation given the nature
 of the problem, however it would have been really interesting to see
 what corruption you had.

If by cheap SSD drive you mean an Indilinx Barefoot based one, we might
be using the same hardware (30GB Vertex in my case). 
What a strange coincidence that it affected git pack files in both cases.
It's almost too improbable...

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-09 Thread Markus Trippelsdorf 
On Wed, Sep 09, 2009 at 09:01:41AM +0200, Jens Axboe wrote:
 On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
  On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
   On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
 On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
  Just got this error today in my dmesg:
  btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 
  43905798
  
  linux % find . -inum 1483065
  ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
  
  It's the main pack file from my git linux kernel tree:
  
 
 Hmm, I ran into something very similar. Care to check what the 
 corrupted
 block of data looks like (and how big it is)?

I've already deleted the file in question unfortunately.
On IRC Chris decided that either bad RAM or a harddrive error was the
most likely reason for this chechsum mismatch.
   
   Darn, that's too bad. The corruption issue I had was also in a git pack
   file. It was fine one day, bad the next. Turned out to be 16kb of 0xff
   in the file, and I blamed it on the (cheap) SSD drive that hosted the
   local git repo. It's still the most likely explanation given the nature
   of the problem, however it would have been really interesting to see
   what corruption you had.
  
  If by cheap SSD drive you mean an Indilinx Barefoot based one, we might
  be using the same hardware (30GB Vertex in my case). 
 
 Spooky, yes indeed that's the very same drive I'm using. Also see my
 postings on this very issue here, top two entries:
 
 http://axboe.livejournal.com/
 
 So that pretty much looks like it reaffirms some of my suspicions. Is
 the drive in a laptop that you suspend and resume?

No. I use it in my workstation, that I never switch off normally.

  What a strange coincidence that it affected git pack files in both cases.
  It's almost too improbable...
 
 Probably more than a coincidence I think, the question is what though...

If it really was an SSD error, then it should happen randomly, messing up
random files. But (contrary to your experience) I never had any issues with 
this SSD until this single failed checksum.

-- 
Markus
--
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: btrfs csum failed on git .pack file

2009-09-08 Thread Markus Trippelsdorf 
On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
 On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
  Just got this error today in my dmesg:
  btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798
  
  linux % find . -inum 1483065
  ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
  
  It's the main pack file from my git linux kernel tree:
  
  linux % ls -l ./.git/objects/pack/
  total 562848
  -rw-r--r-- 1 markus markus   1891324 2008-11-29 19:49 
  pack-011b43fa6956667db5e67fba859e40cb4b154226.idx
  -rw-r--r-- 1 markus markus  44002938 2008-11-29 19:54 
  pack-011b43fa6956667db5e67fba859e40cb4b154226.pack.temp
  -rw-r--r-- 1 markus markus730332 2008-11-29 19:49 
  pack-67be92b3fab3dab175683582dab0b719517e55a5.idx
  -r--r--r-- 1 markus markus  36061684 2009-09-06 21:48 
  pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.idx
  -r--r--r-- 1 markus markus 335202742 2009-09-06 21:48 
  pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
  -rw--- 1 markus markus 158457856 2009-09-07 22:15 tmp_pack_OUdxER
  
  I'm running the latest git kernel and I've been using btrfs as my root
  fs for the last few weeks without problems so far.
 
 Hmm, I ran into something very similar. Care to check what the corrupted
 block of data looks like (and how big it is)?

I've already deleted the file in question unfortunately.
On IRC Chris decided that either bad RAM or a harddrive error was the
most likely reason for this chechsum mismatch.

-- 
Markus
--
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 csum failed on git .pack file

2009-09-07 Thread Markus Trippelsdorf 
Just got this error today in my dmesg:
btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798

linux % find . -inum 1483065
./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack

It's the main pack file from my git linux kernel tree:

linux % ls -l ./.git/objects/pack/
total 562848
-rw-r--r-- 1 markus markus   1891324 2008-11-29 19:49 
pack-011b43fa6956667db5e67fba859e40cb4b154226.idx
-rw-r--r-- 1 markus markus  44002938 2008-11-29 19:54 
pack-011b43fa6956667db5e67fba859e40cb4b154226.pack.temp
-rw-r--r-- 1 markus markus730332 2008-11-29 19:49 
pack-67be92b3fab3dab175683582dab0b719517e55a5.idx
-r--r--r-- 1 markus markus  36061684 2009-09-06 21:48 
pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.idx
-r--r--r-- 1 markus markus 335202742 2009-09-06 21:48 
pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
-rw--- 1 markus markus 158457856 2009-09-07 22:15 tmp_pack_OUdxER

I'm running the latest git kernel and I've been using btrfs as my root
fs for the last few weeks without problems so far.

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

fallocate overhead

2009-08-13 Thread Markus Trippelsdorf 
I was playing with the new hdparm wiper script (
http://sourceforge.net/projects/hdparm/files/) on my Vertex SSD and
it appears that btrfs needs a huge space overhead when dealing with
fallocate system calls. Basically what the wiper script does is to
fallocate one huge file using all free space minus a safety margin.
And this margin has to be about 30% on btrfs, e.g.:

# df -T /
FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/rootbtrfs31266648  10464096  20802552  34% /
# hdparm --fallocate 20002552 test_temp
test_temp: No space left on device
# hdparm --fallocate 16002552 test_temp
test_temp: No space left on device
# hdparm --fallocate 15002552 test_temp
#

and from dmesg:
no space left, need 20482613248, 4096 delalloc bytes, 9786335232 bytes_used, 0 
bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 25545211904 total
no space left, need 16386613248, 4096 delalloc bytes, 9786335232 bytes_used, 0 
bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 25545211904 total

My question is if 30% isn't a bit too much overhead?
-- 
Markus
--
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