Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: anand jain <anand.jain@oracle.com>
To: Olivier Doucet <webmaster@ajeux.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Kernel bug in BTRFS (kernel 3.3.0)
Date: Wed, 18 Apr 2012 12:22:34 +0800	[thread overview]
Message-ID: <4F8E418A.2020801@oracle.com> (raw)
In-Reply-To: <CAPPqfY0T7KmTx=5tcwbUs-zZcB+-yxf01-CWFWY7LUqxepAuNg@mail.gmail.com>


Hi Olivier

 > [370517.204350] btrfs: 1 errors while writing supers
 > [370517.204376] ------------[ cut here ]------------
 > [370517.204391] kernel BUG at fs/btrfs/disk-io.c:2880!

   -----------
       if (total_errors > max_errors) {
           printk(KERN_ERR "btrfs: %d errors while writing supers\n",
                  total_errors);
           /* This shouldn't happen. FUA is masked off if unsupported */
           BUG();
       }
   -----------

   accessible disk(s) is(are) below the critical number of disk(s),
   btrfs has limited choice. IMO instead of BUG, we could have a
   user configurable choice to either panic or fail-pending-IO,
   dump and force-unmount.

 > or if BTRFS failed because of the device.
   yes. Replacing the disk should help here.

HTH

regds, Anand



On 17/04/2012 17:23, Olivier Doucet wrote:
> Hi,
>
> Doing some extensive benchmarks on BTRFS, I encountered a kernel bug
> in BTRFS (as reported in dmesg)
>
> Maybe the information below can help you making btrfs better.
>
> Situation
> Doing an intensive sequential write on a SAS 3TB disk drive (SEAGATE
> ST33000652SS) with 128 threads with Sysbench.
> Device is connected through an HBA. Blocksize was 256k ; Kernel is
> 3.3.0 (x86_64) ; Btrfs is version v0.19
>
> Write is done through an LVS volume formated with BTRFS of course;
> Mount options are : rw,noatime,nodiratime,compress=lzo,nospace_cache
>
> Dmesg gives me following error :
>
> [370517.203926] sd 0:0:15:0: [sdo] Device not ready
> [370517.203930] sd 0:0:15:0: [sdo]  Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [370517.203935] sd 0:0:15:0: [sdo]  Sense Key : Not Ready [current]
> [370517.203940] sd 0:0:15:0: [sdo]  ASC=0x4<<vendor>>  ASCQ=0xf2
> [370517.203946] sd 0:0:15:0: [sdo] CDB: Write(10): 2a 00 00 00 6a 00 00 00 80 00
> [370517.203955] end_request: I/O error, dev sdo, sector 27136
> [370517.204236] sd 0:0:15:0: [sdo] Device not ready
> [370517.204240] sd 0:0:15:0: [sdo]  Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [370517.204244] sd 0:0:15:0: [sdo]  Sense Key : Not Ready [current]
> [370517.204249] sd 0:0:15:0: [sdo]  ASC=0x4<<vendor>>  ASCQ=0xf2
> [370517.204255] sd 0:0:15:0: [sdo] CDB: Write(10): 2a 00 00 00 08 80 00 00 08 00
> [370517.204265] end_request: I/O error, dev sdo, sector 2176
> [370517.204283] lost page write due to I/O error on dm-5
> [370517.204350] btrfs: 1 errors while writing supers
> [370517.204376] ------------[ cut here ]------------
> [370517.204391] kernel BUG at fs/btrfs/disk-io.c:2880!
> [370517.204406] invalid opcode: 0000 [#1] SMP
> [370517.204423] CPU 2
> [370517.204436] Pid: 8790, comm: sysbench Not tainted 3.3.0-oxeva #2
> Supermicro X8DTT-H/X8DTT-H
> [370517.204482] RIP: 0010:[<ffffffff81389e63>]  [<ffffffff81389e63>]
> write_all_supers+0x833/0x840
> [370517.204508] RSP: 0018:ffff880e52f63b68  EFLAGS: 00010292
> [370517.204522] RAX: 000000000000003b RBX: ffff88100ef81f38 RCX:
> 0000000000000068
> [370517.204539] RDX: 0000000000000000 RSI: 0000000000000046 RDI:
> ffffffff81f9c6b0
> [370517.204556] RBP: ffff880e52f63bd8 R08: 0000000000000000 R09:
> ffffffff81bba980
> [370517.204573] R10: 0000000000000001 R11: 0000000000000000 R12:
> ffff880e52f63ba0
> [370517.204592] R13: ffff88100ef81f38 R14: ffff881010902000 R15:
> 0000000000000001
> [370517.204829] FS:  00007f3a2300c700(0000) GS:ffff88081fc40000(0000)
> knlGS:0000000000000000
> [370517.204954] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [370517.205024] CR2: 00007f3a24b9e998 CR3: 0000000ce9963000 CR4:
> 00000000000006e0
> [370517.205147] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [370517.205269] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [370517.205393] Process sysbench (pid: 8790, threadinfo
> ffff880e52f62000, task ffff881008902880)
> [370517.205519] Stack:
> [370517.205580]  ffff88101090210b ffff88100ef81ec0 0000000052f63ba8
> 0000000100000001
> [370517.205716]  ffff881010d59000 ffff881000000001 ffff880811d87400
> ffff88100ef81f38
> [370517.205849]  00000013c4a03fff ffff880ff058d000 ffff880811d87400
> ffff881002a915a0
> [370517.205984] Call Trace:
> [370517.206049]  [<ffffffff81389e7e>] write_ctree_super+0xe/0x10
> [370517.206119]  [<ffffffff813c24b4>] btrfs_sync_log+0x424/0x5c0
> [370517.206190]  [<ffffffff8139e9cb>] btrfs_sync_file+0x17b/0x1e0
> [370517.206260]  [<ffffffff81160703>] vfs_fsync_range+0x23/0x30
> [370517.206329]  [<ffffffff8116076c>] generic_write_sync+0x3c/0x40
> [370517.206399]  [<ffffffff8139f4a7>] btrfs_file_aio_write+0x317/0x530
> [370517.206472]  [<ffffffff8113556a>] do_sync_write+0xda/0x120
> [370517.206544]  [<ffffffff8110037f>] ? handle_mm_fault+0x1af/0x320
> [370517.206614]  [<ffffffff81135ab8>] vfs_write+0xc8/0x190
> [370517.206682]  [<ffffffff81135c12>] sys_pwrite64+0x92/0xa0
> [370517.206753]  [<ffffffff81aa82e2>] system_call_fastpath+0x16/0x1b
> [370517.206820] Code: e9 72 fe ff ff 44 89 d6 48 c7 c7 b8 68 d2 81 31
> c0 e8 43 b1 71 00 0f 0b eb fe 8b 75 b8 48 c7 c7 b8 68 d2 81 31 c0 e8
> 2e b1 71 00<0f>  0b eb fe 66 0f 1f 84 00 00 00 00 00 55 48 89 f7 48 89
> e5 89
> [370517.207167] RIP  [<ffffffff81389e63>] write_all_supers+0x833/0x840
> [370517.207239]  RSP<ffff880e52f63b68>
> [370517.207673] ---[ end trace f208fa157676276c ]---
>
>
> I don't know if the device failed because BTRFS did something wrong,
> or if BTRFS failed because of the device.
>
> After this error, device cannot be accessed anymore (stuck and fdisk
> returned no info, neither do smartctl - just 'device busy').
>
> By the way, I'm actually doing some extensive benchmarks, comparing
> BTRFS with XFS or EXT4. I'll post results on this mailing list in a
> few days, I'm sure it can be interested for you.
>
> Olivier
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-04-18  4:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17  9:23 Kernel bug in BTRFS (kernel 3.3.0) Olivier Doucet
2012-04-18  4:22 ` anand jain [this message]
2012-04-18  9:25   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8E418A.2020801@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=webmaster@ajeux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox