From: Pim van den Berg <pim.vandenberg-IXGSG4U2CCrz+pZb47iToQ@public.gmane.org>
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: mkfs crash
Date: Thu, 27 Dec 2012 13:05:11 +0100 [thread overview]
Message-ID: <50DC3977.2080209@nethuis.nl> (raw)
Hi,
I'm successfully using bcache on 1 partition of my system for a while
now. The SSD is split in 2 partitions to be able to enable bcache on
another partition too.
The first partition is setup like this:
/dev/md3 (mdadm, RAID1, bcache backing device)
- /dev/bcache0
I tried to setup the second partition like this:
/dev/md4 (mdadm, RAID1)
- /dev/dm-0 (luks, bcache backing device)
- /dev/bcache3
All goes well until I try to create an ext4 (or ext3) filesystem on it.
The mkfs command crashes and couple of 1000 lines show up in my syslog
(the full log is over here:
http://pommi.nethuis.nl/storage/software/bcache/log/mkfs-crash.log):
[1631972.332656] bcache: Caching dm-0 as bcache3 on set
6bc79688-a6e0-4c21-8f44-59b0083b8169
[1631983.772362] CPU 0
[1631983.772380] Pid: 28707, comm: mkfs.ext4 Not tainted 3.2.33-kvm
#1 /DH67CF
[1631983.772420] RIP: 0010:[<ffffffff813f91ca>] [<ffffffff813f91ca>]
bch_mark_sectors_bypassed+0x1a/0x35
[1631983.772465] RSP: 0018:ffff880165cadbf8 EFLAGS: 00000a06
[1631983.772486] RAX: ffff8801128e0010 RBX: ffff880165fd0318 RCX:
ffff880165cadc30
[1631983.772521] RDX: 2000000000000000 RSI: 00000000007fffff RDI:
ffff880165fd0318
[1631983.772556] RBP: ffff880165cadbf8 R08: ffff88021e802be0 R09:
00000000ffffff02
[1631983.772592] R10: 00000000ffffff01 R11: ffff880165cadc78 R12:
ffff8801128e0000
[1631983.772627] R13: ffff880118450000 R14: ffff880165cadc68 R15:
0000000000000000
[1631983.772662] FS: 000067d4ad65e760(0000) GS:ffff88021fa00000(0000)
knlGS:0000000000000000
[1631983.772699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1631983.772722] CR2: 0000000001958908 CR3: 0000000163c68000 CR4:
00000000000406f0
[1631983.772757] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1631983.772792] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[1631983.772827] Process mkfs.ext4 (pid: 28707, threadinfo
ffff880133edacf0, task ffff880133eda800)
[1631983.772880] ffff880165cadc48 ffffffff813f08dc 0000001065cadc48
ffff880163fe0000
[1631983.772919] ffff8801128e0000 ffff880165fd0318 ffff8801128e0000
ffff880165fd0378
[1631983.772957] ffff880165cadc68 ffff880165cadc58 ffff880165cadca8
ffffffff813f1ae0
[1631983.773015] [<ffffffff813f08dc>] check_should_skip+0x31f/0x335
[1631983.773039] [<ffffffff813f1ae0>] request_write+0x7d/0x267
[1631983.773061] [<ffffffff813f1dc8>] cached_dev_make_request+0xfe/0x1ad
[1631983.773087] [<ffffffff8127edff>] generic_make_request+0x17c/0x1d2
[1631983.773110] [<ffffffff8127ef25>] submit_bio+0xd0/0xdb
[1631983.773133] [<ffffffff81284a3d>] blkdev_issue_discard+0x158/0x1a7
[1631983.773156] [<ffffffff812850bb>] blkdev_ioctl+0x2f7/0x69c
[1631983.773180] [<ffffffff811191f8>] block_ioctl+0x32/0x36
[1631983.773203] [<ffffffff810fe7e2>] do_vfs_ioctl+0x5aa/0x5fa
[1631983.773226] [<ffffffff810fe874>] sys_ioctl+0x42/0x65
[1631983.773250] [<ffffffff815657b6>] system_call_fastpath+0x18/0x1d
[1631983.773384] Call Trace:
[1631983.773401] [<ffffffff813f08dc>] check_should_skip+0x31f/0x335
[1631983.773424] [<ffffffff813f1ae0>] request_write+0x7d/0x267
[1631983.773447] [<ffffffff813f1dc8>] cached_dev_make_request+0xfe/0x1ad
[1631983.773470] [<ffffffff8127edff>] generic_make_request+0x17c/0x1d2
[1631983.773499] [<ffffffff8127ef25>] submit_bio+0xd0/0xdb
[1631983.773520] [<ffffffff81284a3d>] blkdev_issue_discard+0x158/0x1a7
[1631983.773544] [<ffffffff812850bb>] blkdev_ioctl+0x2f7/0x69c
[1631983.773567] [<ffffffff811191f8>] block_ioctl+0x32/0x36
[1631983.773590] [<ffffffff810fe7e2>] do_vfs_ioctl+0x5aa/0x5fa
[1631983.773613] [<ffffffff810fe874>] sys_ioctl+0x42/0x65
[1631983.773635] [<ffffffff815657b6>] system_call_fastpath+0x18/0x1d
I'm using the 3.2.33 Linux kernel with
grsecurity-2.9.1-3.2.33-201211072000 and bcache v3.2.28-384-gcafb412.
I've tried to set it up this way multiple times but I hit the same
problem each time. Because I'm successfully running bcache on a mdadm
device, I thought there was an issue with the luks part. So I tested
this part with a USB thumb drive as a backing device:
/dev/sdd
- /dev/dm-0 (luks, bcache backing device)
- /dev/bcache1
In this case the bcache device worked without a problem. As you can see
in the stacktrace, bch_mark_sectors_bypassed (a piece of bcache code)
causes the crash. Do you know what is going wrong here?
--
Regards,
Pim
next reply other threads:[~2012-12-27 12:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-27 12:05 Pim van den Berg [this message]
[not found] ` <50DC3977.2080209-IXGSG4U2CCrz+pZb47iToQ@public.gmane.org>
2012-12-28 4:31 ` mkfs crash Kent Overstreet
[not found] ` <20121228043144.GC10411-jC9Py7bek1znysI04z7BkA@public.gmane.org>
2012-12-29 11:53 ` Pim van den Berg
[not found] ` <50DED9A0.40002-IXGSG4U2CCrz+pZb47iToQ@public.gmane.org>
2012-12-29 20:28 ` Pim van den Berg
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=50DC3977.2080209@nethuis.nl \
--to=pim.vandenberg-ixgsg4u2ccrz+pzb47itoq@public.gmane.org \
--cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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.