All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.