Re: bug when removing device
I have sent a set of patches that address bugs like this. I applied the V2 patchset to kernel-v2.6.32 (actually, I applied them to btrfs-unstalbe, took a kernel-v2.6.32 and replaced its btrfs with the patched one in btrfs-unstable), and did the test, then got: $ sudo btrfs device del /dev/loop1 /tmp/mnt0/ ERROR: error removing the device '/dev/loop1' $ sudo btrfs device del /dev/loop0 /tmp/mnt0/ ERROR: error removing the device '/dev/loop0' dmesg: [ 3463.136786] btrfs: unable to remove the only writeable device [ 3468.205188] btrfs: unable to remove the only writeable device Is it something wrong? -- 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: bug when removing device
On Thu, Apr 29, 2010 at 2:11 AM, sniper s3c2...@gmail.com wrote: Hi all, I tried to reproduce the bug reported by Tomas Thiemel (http://www.spinics.net/lists/linux-btrfs/msg04818.html) with loop device, and caught a bug report. kernel: v2.6.34-rc5-279-g1600f9d btrfs_progs: v0.19-16-g075587c cd /tmp mkdir mnt0 mkdir mnt1 dd if=/dev/zero of=./disk0 bs=1M count=500 cp disk0 disk1 sudo losetup /dev/loop0 ./disk0 sudo losetup /dev/loop1 ./disk1 sudo mkfs.btrfs /dev/loop0 sudo mkfs.btrfs /dev/loop1 sudo mount -t btrfs /dev/loop0 /tmp/mnt0 sudo chmod 777 ./mnt0 cp something to mnt0 to make it about 90% full. sync sudo btrfs device add /dev/loop1 /tmp/mnt0/ sudo btrfs device del /dev/loop0 /tmp/mnt0/ [ 62.633654] Btrfs loaded [ 62.683562] device fsid f54c8635a7be86e1-bbbda7c901fc86bc devid 1 transid 3244 /dev/sda3 [ 146.235105] device fsid e6427ac6ae899005-2bbefc65da08e8e devid 1 transid 7 /dev/loop0 [ 283.259210] btrfs: relocating block group 465567744 flags 1 [ 283.546271] btrfs: relocating block group 398458880 flags 1 [ 284.081040] btrfs: found 87 extents [ 285.807272] btrfs: found 87 extents [ 286.011543] btrfs: relocating block group 331350016 flags 1 [ 286.609884] btrfs: found 4238 extents [ 288.990953] btrfs: found 4238 extents [ 289.283116] btrfs: relocating block group 264241152 flags 1 [ 289.905397] btrfs: found 130 extents [ 291.474489] btrfs: found 130 extents [ 291.646969] btrfs: relocating block group 197132288 flags 1 [ 292.121484] btrfs: found 236 extents [ 293.781097] btrfs: found 236 extents [ 293.979469] btrfs: relocating block group 130023424 flags 1 [ 294.483698] btrfs: found 208 extents [ 296.108372] btrfs: found 208 extents [ 296.328261] btrfs: relocating block group 62914560 flags 1 [ 296.822185] btrfs: found 123 extents [ 298.424613] btrfs: found 123 extents [ 298.574020] btrfs: relocating block group 20971520 flags 34 [ 298.659502] btrfs allocation failed flags 34, wanted 4096 [ 298.659509] space_info has 8384512 free, is full [ 298.659514] space_info total=8388608, pinned=0, delalloc=0, may_use=0, used=4096, root=0, super=0, reserved=0 [ 298.659519] block group 20971520 has 8388608 bytes, 4096 used 0 pinned 0 reserved [ 298.659524] entry offset 20975616, bytes 8384512, bitmap no [ 298.659527] block group has cluster?: no [ 298.659530] 1 blocks of free space at or bigger than bytes is [ 298.659562] [ cut here ] [ 298.659565] kernel BUG at fs/btrfs/relocation.c:2146! [ 298.659569] invalid opcode: [#1] SMP [ 298.659575] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 298.659579] Modules linked in: btrfs zlib_deflate crc32c libcrc32c binfmt_misc xt_TCPMSS xt_tcpmss xt_tcpudp iptable_mangle ip_tables x_tables pppoe pppox ppdev parport_pc snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel fbcon tileblit snd_hda_codec font snd_hwdep bitblit softcursor snd_pcm_oss arc4 snd_mixer_oss snd_pcm joydev snd_seq_dummy snd_seq_oss snd_seq_midi uvcvideo nouveau snd_rawmidi ttm drm_kms_helper sdhci_pci videodev video sdhci iwlagn psmouse v4l1_compat output snd_seq_midi_event lp led_class iwlcore drm intel_agp snd_seq serio_raw agpgart i2c_algo_bit parport snd_timer snd_seq_device snd jmb38x_ms memstick soundcore snd_page_alloc mac80211 cfg80211 usbhid ohci1394 hid usb_storage tg3 ieee1394 [ 298.659679] [ 298.659685] Pid: 2179, comm: btrfs Not tainted 2.6.34-rc5-custom #1 KL1 /IdeaPad Y450 [ 298.659691] EIP: 0060:[f85f3b7e] EFLAGS: 00010286 CPU: 1 [ 298.659710] EIP is at relocate_tree_blocks+0x52e/0x590 [btrfs] [ 298.659714] EAX: cd096dc0 EBX: cd1a83c0 ECX: cd096940 EDX: [ 298.659718] ESI: 0008 EDI: cd096dc0 EBP: cd333c74 ESP: cd333c14 [ 298.659722] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 298.659727] Process btrfs (pid: 2179, ti=cd332000 task=f6beb340 task.ti=cd332000) [ 298.659730] Stack: [ 298.659733] cd096554 f6e0eb60 cd096540 0140 cd333c74 f6331800 [ 298.659744] 0 cd333ccc ffe4 f69bbe40 ed57d570 f6e0eb60 cd1a83fc 0100 [ 298.659756] 0 d800 0001 fffa2000 0002 f6e0eaf0 f69bbe40 [ 298.659768] Call Trace: [ 298.659788] [f85f3e0f] ? relocate_block_group+0x22f/0x430 [btrfs] [ 298.659807] [f85b23d3] ? btrfs_clean_old_snapshots+0x63/0xf0 [btrfs] [ 298.659824] [f85f4187] ? btrfs_relocate_block_group+0x177/0x350 [btrfs] [ 298.659842] [f85d920e] ? btrfs_relocate_chunk+0x6e/0x520 [btrfs] [ 298.659850] [c0130370] ? kunmap_atomic+0x60/0x70 [ 298.659869] [f85cf451] ? unmap_extent_buffer+0x11/0x20 [btrfs] [ 298.659889] [f85c5610] ? btrfs_dev_extent_chunk_offset+0xe0/0xf0 [btrfs] [ 298.659907] [f85d996e] ? btrfs_shrink_device+0x2ae/0x3e0 [btrfs] [ 298.659925] [f85d9c5d] ? btrfs_rm_device+0x1bd/0x530 [btrfs] [ 298.659933] [c01cc2fb] ? filemap_fault+0xbb/0x400 [
[PATCH] btrfs: fix shadows sparse warning
Fix sparse warnings:
fs/btrfs/free-space-cache.c:1078:40: warning: symbol 'node' shadows an earlier
one
fs/btrfs/free-space-cache.c:1230:32: warning: symbol 'node' shadows an earlier
one
Signed-off-by: Bill Pemberton wf...@virginia.edu
---
fs/btrfs/free-space-cache.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index f488fac..c0d91fb 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -1075,8 +1075,6 @@ u64 btrfs_alloc_from_cluster(struct
btrfs_block_group_cache *block_group,
while(1) {
if (entry-bytes bytes || entry-offset min_start) {
- struct rb_node *node;
-
node = rb_next(entry-offset_index);
if (!node)
break;
@@ -1227,7 +1225,7 @@ again:
*/
while (entry-bitmap || found_bitmap ||
(!entry-bitmap entry-bytes min_bytes)) {
- struct rb_node *node = rb_next(entry-offset_index);
+ node = rb_next(entry-offset_index);
if (entry-bitmap entry-bytes bytes + empty_size) {
ret = btrfs_bitmap_cluster(block_group, entry, cluster,
--
1.7.0.6
--
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
Updating RAID[56] support
I've been looking again at the RAID5/RAID6 support, and updated the tree
at git://git.infradead.org/users/dwmw2/btrfs-raid56.git#merged
At the moment, we limit writes to a single disk's worth at a time, which
means we _always_ do the read-calculateparity-write cycle and suffer the
traditional RAID 'write hole' problem.
We need to fix the upper layers so that it'll _always_ write a full
stripe, which Chris has promised to do. When that's done, we can rip out
the whole raid56_parity_write_partial() and raid_read_end_io() and
raid_hack_mutex crap.
But first I needed to actually make the RAID code _cope_ with a full
stripe at a time, which for some reason I hadn't already done. That's
what this patch attempts to do.
(It also sets the stripe size to 4KiB/disk so that we can use it on a
4-disk RAID6 and be sure we'll only ever be asked to write either
precisely one disk's worth as before, or the whole stripe -- I've not
attempted to make it cope with anything in-between. That's a simple hack
for short-term testing purposes, which needs to be done in mkfs.btrfs
too.)
It seems to work, and recovery is successful when I mount the file
system with -oro,degraded. But in read-write mode it'll oops (even
without the below patch) because it's trying to _write_ to the degraded
RAID6. Last time I was testing this, it wouldn't continue to write to
that block group; it would allocate a new one which didn't include the
missing disk. What changed?
The thing I really don't like about this patch is the handling of the
returned map_length from __btrfs_map_block(), for full-stripe writes.
Suggestions on a postcard to...
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 32eabf1..70dc314 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2226,7 +2226,7 @@ static int __btrfs_alloc_chunk(struct btrfs_trans_handle
*trans,
int looped = 0;
int ret;
int index;
- int stripe_len = 64 * 1024;
+ int stripe_len = 4 * 1024;
if ((type BTRFS_BLOCK_GROUP_RAID1)
(type BTRFS_BLOCK_GROUP_DUP)) {
@@ -2735,6 +2735,7 @@ static int __btrfs_map_block(struct btrfs_mapping_tree
*map_tree, int rw,
u64 offset;
u64 stripe_offset;
u64 stripe_nr;
+ u64 stripe_len;
u64 *raid_map = NULL;
int stripes_allocated = 8;
int stripes_required = 1;
@@ -2816,13 +2817,24 @@ again:
goto again;
}
stripe_nr = offset;
+
+ stripe_len = map-stripe_len;
+ if (!multi_ret !unplug_page (rw (1 BIO_RW))
+ map-type (BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6)) {
+ /*
+* For the merge_bio_hook() we allow _writes_ (but not reads)
+* to cover a full stripe-set.
+*/
+ stripe_len *= nr_data_stripes(map);
+ printk(Stripe_len becomes %llx\n, stripe_len);
+ }
/*
* stripe_nr counts the total number of stripes we have to stride
* to get to this block
*/
- do_div(stripe_nr, map-stripe_len);
+ do_div(stripe_nr, stripe_len);
- stripe_offset = stripe_nr * map-stripe_len;
+ stripe_offset = stripe_nr * stripe_len;
BUG_ON(offset stripe_offset);
/* stripe_offset is the offset of this block in its stripe*/
@@ -2833,8 +2845,21 @@ again:
BTRFS_BLOCK_GROUP_RAID10 |
BTRFS_BLOCK_GROUP_DUP)) {
/* we limit the length of each bio to what fits in a stripe */
- *length = min_t(u64, em-len - offset,
- map-stripe_len - stripe_offset);
+ /* For writes to RAID[56], allow a full stripe, not just a
single
+ disk's worth */
+ if (map-type (BTRFS_BLOCK_GROUP_RAID5 |
BTRFS_BLOCK_GROUP_RAID6)
+ !stripe_offset multi_ret raid_map_ret (rw (1
BIO_RW))) {
+ *length = min_t(u64, em-len - offset,
+ stripe_len * nr_data_stripes(map));
+ printk(len becomes %Lx for RAID[56] write
(min(%Lx,%Lx))\n, *length,
+ em-len - offset, stripe_len *
nr_data_stripes(map));
+ } else {
+ *length = min_t(u64, em-len - offset,
+ stripe_len - stripe_offset);
+ printk(len becomes %Lx (min(%Lx,%Lx))\n, *length,
+ em-len - offset, stripe_len - stripe_offset);
+ }
+
} else {
*length = em-len - offset;
}
@@ -3173,6 +3198,7 @@ int btrfs_map_bio(struct btrfs_root *root, int rw, struct
bio *bio,
int ret;
int dev_nr = 0;
int total_devs = 1;
+ printk(%s %d %d %llx %x\n, __func__, rw, mirror_num, logical,
bio-bi_size);
length = bio-bi_size;
Undo mkfs.btrfs
I accidentally did a mkfs.btrfs on a used btrfs filesystem, which now shows as empty. Is there any way to get the data back? -- 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
Segmentation fault on partition mount
My distro: Archlinux Kernel: 2.6.34-rc5, 2.6.33.3 I has 522 Gib btrfs partition and. While I was checking out chromium source, free space on my /home btrfs partition was about 20 Gib. Then I received message not enough free space (but there was enough of it). And even after btrfsck I always get segmentation fault. Even btrfs-debug-tree can't be done successfully. How can this bug be fixed? P.S. I can't find btrfs-image in btrfs-progs-unstable from the Archlinux repo. -- 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 balance failed and kernel oops'd
Hi Justin, I use Gentoo and I had Kernel OOPS, too (with 2.6.33), until I upgraded to the lastest not stable kernel - 2.6.34-rc5. Now (almost) everything works OK. I also had to re-format partition because there is one small problem: When you add disk (in single mode) and then you rebalance partition, it changes data mode from single to RAID0 so you cannot remove added disk any more :-( I also use latest unstable btrfs-progs (Btrfs v0.19-16-g075587c-dirty) to enable all the bells and whistles. Tomas Thiemel -- 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: Updating RAID[56] support
On Thu, Apr 29, 2010 at 07:06:06PM +0100, David Woodhouse wrote: I've been looking again at the RAID5/RAID6 support, and updated the tree at git://git.infradead.org/users/dwmw2/btrfs-raid56.git#merged At the moment, we limit writes to a single disk's worth at a time, which means we _always_ do the read-calculateparity-write cycle and suffer the traditional RAID 'write hole' problem. We need to fix the upper layers so that it'll _always_ write a full stripe, which Chris has promised to do. When that's done, we can rip out the whole raid56_parity_write_partial() and raid_read_end_io() and raid_hack_mutex crap. But first I needed to actually make the RAID code _cope_ with a full stripe at a time, which for some reason I hadn't already done. That's what this patch attempts to do. (It also sets the stripe size to 4KiB/disk so that we can use it on a 4-disk RAID6 and be sure we'll only ever be asked to write either precisely one disk's worth as before, or the whole stripe -- I've not attempted to make it cope with anything in-between. That's a simple hack for short-term testing purposes, which needs to be done in mkfs.btrfs too.) It seems to work, and recovery is successful when I mount the file system with -oro,degraded. But in read-write mode it'll oops (even without the below patch) because it's trying to _write_ to the degraded RAID6. Last time I was testing this, it wouldn't continue to write to that block group; it would allocate a new one which didn't include the missing disk. What changed? Maybe that block group isn't getting marked read only? I'd need to see the oops to know what was going on. Thanks, Josef -- 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: Segmentation fault on partition mount
On Fri, Apr 30, 2010 at 11:26:16AM -0700, Ilya Shestopalov wrote: My distro: Archlinux Kernel: 2.6.34-rc5, 2.6.33.3 I has 522 Gib btrfs partition and. While I was checking out chromium source, free space on my /home btrfs partition was about 20 Gib. Then I received message not enough free space (but there was enough of it). And even after btrfsck I always get segmentation fault. Even btrfs-debug-tree can't be done successfully. How can this bug be fixed? P.S. I can't find btrfs-image in btrfs-progs-unstable from the Archlinux repo. So you may have run out of metadata space. If you run btrfs filesystem df /mnt/point it will tell you the block groups and how much space is in them. You may want to do a btrfs-vol -b /mnt/point. Thanks, Josef -- 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: Updating RAID[56] support
- David Woodhouse dw...@infradead.org skrev: I've been looking again at the RAID5/RAID6 support, and updated the tree at git://git.infradead.org/users/dwmw2/btrfs-raid56.git#merged At the moment, we limit writes to a single disk's worth at a time, which means we _always_ do the read-calculateparity-write cycle and suffer the traditional RAID 'write hole' problem. Out of curiosity, will Btrfs allow for variable block sizes such as with ZFS? roy -- 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: Updating RAID[56] support
On Fri, 2010-04-30 at 14:39 -0400, Josef Bacik wrote: It seems to work, and recovery is successful when I mount the file system with -oro,degraded. But in read-write mode it'll oops (even without the below patch) because it's trying to _write_ to the degraded RAID6. Last time I was testing this, it wouldn't continue to write to that block group; it would allocate a new one which didn't include the missing disk. What changed? Maybe that block group isn't getting marked read only? I'd need to see the oops to know what was going on. Thanks, Yes, it's not getting marked read-only. All the asynchronicity means that there isn't a clear backtrace. I put extra checks in different places a few times, and the closest I got was WARNING: at fs/btrfs/volumes.c:3913 btrfs_map_bio+0x482/0x6c2 [btrfs]() [a019bbf6] btrfs_map_bio+0x482/0x6c2 [btrfs] [a01777c1] __btree_submit_bio_done+0x16/0x18 [btrfs] [a0178d2f] run_one_async_done+0x8d/0x92 [btrfs] [a019f0c7] run_ordered_completions+0x73/0xbe [btrfs] From a check for !device-bdev in raid56_parity_write(). -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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
[no subject]
Bug message: Btrfs loaded device fsid 694983118c1865e7-ed2ca7537412e6ae devid 1 transid 73188 /dev/sda5 [ cut here ] kernel BUG at fs/btrfs/tree-log.c:809! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:1f.2/host3/target3:0:0/3:0:0:0/scsi_level Modules linked in: btrfs zlib_deflate crc32c libcrc32c fuse usbhid hid snd_hda_codec_analog snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc rtc_cmos rtc_core rtc_lib uhci_hcd asus_atk0110 nvidia(P) agpgart firewire_ohci firewire_core crc_itu_t ehci_hcd usbcore i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support thermal button processor sky2 x38_edac edac_core sg evdev pcspkr ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom floppy pata_jmicron ata_piix pata_acpi ata_generic libata scsi_mod Pid: 2889, comm: mount Tainted: P 2.6.33-ARCH #1 P5E/P5E EIP: 0060:[f9f468b9] EFLAGS: 00010246 CPU: 1 EIP is at add_inode_ref+0x3e9/0x400 [btrfs] EAX: EBX: 0097 ECX: EDX: 00a9 ESI: 0002 EDI: f6ea4b40 EBP: f69e9c40 ESP: f69e9be4 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process mount (pid: 2889, ti=f69e8000 task=f653e1a0 task.ti=f69e8000) Stack: f69e9bf8 f69e9bf8 c102ade0 f6ea4b40 0011 f69e9c00 f9f3991c f69e9c40 0 f9f2e36f f69e9c30 f6ea5000 f6df83dc 0004 f6ea4b40 0 f681 f6810800 fffa3000 fffa3000 0097 0002 f6ea4b40 f69e9ca4 Call Trace: [c102ade0] ? kunmap_atomic+0x70/0x80 [f9f3991c] ? unmap_extent_buffer+0xc/0x10 [btrfs] [f9f2e36f] ? btrfs_item_size+0xdf/0xf0 [btrfs] [f9f477fe] ? replay_one_buffer+0x23e/0x310 [btrfs] [f9f44d70] ? walk_down_log_tree+0x210/0x510 [btrfs] [f9f45111] ? walk_log_tree+0xa1/0x1c0 [btrfs] [f9f4962b] ? btrfs_recover_log_trees+0x1cb/0x290 [btrfs] [f9f475c0] ? replay_one_buffer+0x0/0x310 [btrfs] [f9f14f58] ? open_ctree+0x10b8/0x15d0 [btrfs] [c1185249] ? strlcpy+0x39/0x50 [f9ef8760] ? btrfs_get_sb+0x310/0x3f0 [btrfs] [c10ed24a] ? __alloc_percpu+0xa/0x10 [c110be56] ? alloc_vfsmnt+0xe6/0x140 [c10f69b1] ? vfs_kern_mount+0x61/0x1b0 [c110ac87] ? get_fs_type+0x97/0xb0 [c10f6b59] ? do_kern_mount+0x39/0xe0 [c110d398] ? do_mount+0x358/0x700 [c10cf0c4] ? strndup_user+0x44/0x80 [c110d9e6] ? sys_mount+0x66/0xa0 [c100371f] ? sysenter_do_call+0x12/0x28 Code: 8b 45 e4 e8 ca 39 fb ff 8b 45 d4 e8 e2 15 1c c7 8b 45 cc e8 da 15 1c c7 31 c0 83 c4 50 5b 5e 5f 5d c3 b8 fe ff ff ff eb f1 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 8d 74 26 00 8d bc 27 00 00 EIP: [f9f468b9] add_inode_ref+0x3e9/0x400 [btrfs] SS:ESP 0068:f69e9be4 ---[ end trace 1d3c13495ff7bd0e ]--- -- 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: Re: Segmentation fault on partition mount
Bug message: Btrfs loaded device fsid 694983118c1865e7-ed2ca7537412e6ae devid 1 transid 73188 /dev/sda5 [ cut here ] kernel BUG at fs/btrfs/tree-log.c:809! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:1f.2/host3/target3:0:0/3:0:0:0/scsi_level Modules linked in: btrfs zlib_deflate crc32c libcrc32c fuse usbhid hid snd_hda_codec_analog snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc rtc_cmos rtc_core rtc_lib uhci_hcd asus_atk0110 nvidia(P) agpgart firewire_ohci firewire_core crc_itu_t ehci_hcd usbcore i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support thermal button processor sky2 x38_edac edac_core sg evdev pcspkr ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom floppy pata_jmicron ata_piix pata_acpi ata_generic libata scsi_mod Pid: 2889, comm: mount Tainted: P 2.6.33-ARCH #1 P5E/P5E EIP: 0060:[f9f468b9] EFLAGS: 00010246 CPU: 1 EIP is at add_inode_ref+0x3e9/0x400 [btrfs] EAX: EBX: 0097 ECX: EDX: 00a9 ESI: 0002 EDI: f6ea4b40 EBP: f69e9c40 ESP: f69e9be4 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process mount (pid: 2889, ti=f69e8000 task=f653e1a0 task.ti=f69e8000) Stack: f69e9bf8 f69e9bf8 c102ade0 f6ea4b40 0011 f69e9c00 f9f3991c f69e9c40 0 f9f2e36f f69e9c30 f6ea5000 f6df83dc 0004 f6ea4b40 0 f681 f6810800 fffa3000 fffa3000 0097 0002 f6ea4b40 f69e9ca4 Call Trace: [c102ade0] ? kunmap_atomic+0x70/0x80 [f9f3991c] ? unmap_extent_buffer+0xc/0x10 [btrfs] [f9f2e36f] ? btrfs_item_size+0xdf/0xf0 [btrfs] [f9f477fe] ? replay_one_buffer+0x23e/0x310 [btrfs] [f9f44d70] ? walk_down_log_tree+0x210/0x510 [btrfs] [f9f45111] ? walk_log_tree+0xa1/0x1c0 [btrfs] [f9f4962b] ? btrfs_recover_log_trees+0x1cb/0x290 [btrfs] [f9f475c0] ? replay_one_buffer+0x0/0x310 [btrfs] [f9f14f58] ? open_ctree+0x10b8/0x15d0 [btrfs] [c1185249] ? strlcpy+0x39/0x50 [f9ef8760] ? btrfs_get_sb+0x310/0x3f0 [btrfs] [c10ed24a] ? __alloc_percpu+0xa/0x10 [c110be56] ? alloc_vfsmnt+0xe6/0x140 [c10f69b1] ? vfs_kern_mount+0x61/0x1b0 [c110ac87] ? get_fs_type+0x97/0xb0 [c10f6b59] ? do_kern_mount+0x39/0xe0 [c110d398] ? do_mount+0x358/0x700 [c10cf0c4] ? strndup_user+0x44/0x80 [c110d9e6] ? sys_mount+0x66/0xa0 [c100371f] ? sysenter_do_call+0x12/0x28 Code: 8b 45 e4 e8 ca 39 fb ff 8b 45 d4 e8 e2 15 1c c7 8b 45 cc e8 da 15 1c c7 31 c0 83 c4 50 5b 5e 5f 5d c3 b8 fe ff ff ff eb f1 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 8d 74 26 00 8d bc 27 00 00 EIP: [f9f468b9] add_inode_ref+0x3e9/0x400 [btrfs] SS:ESP 0068:f69e9be4 ---[ end trace 1d3c13495ff7bd0e ]--- -- 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
