# btrfs BUG oder QEMU - Problem?

## LinuxTom

Hi Leute,

bei dem Kernel 3.5.7 fliegt mir immer das BTRFS-Dateisystem weg. Leider "vergisst" es da immer die Hälfte und das System wrrd unbrauchbar. Hat Einer von Euch das auch festgestellt und die Ursache herausgefunden? Ich bin für Hilfe Dankbar, da ich dadurch wieder auf das ReiserFS zurück muss.

```
Sep 30 15:36:22 localhost kernel: ------------[ cut here ]------------

Sep 30 15:36:22 localhost kernel: kernel BUG at fs/btrfs/extent-tree.c:5079!

Sep 30 15:36:22 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP 

Sep 30 15:36:22 localhost kernel: Modules linked in: ipv6 dm_mod cachefiles fscache vboxnetadp(O) vboxnetflt(O) vboxdrv(O) microcode pcspkr snd_hda_intel snd_hda_codec snd_pcm snd_page_alloc snd_timer snd soundcore i2c_piix4 i2c_core floppy

Sep 30 15:36:22 localhost kernel: 

Sep 30 15:36:22 localhost kernel: Pid: 16425, comm: rm Tainted: G           O 3.5.7-gentoo #1 Bochs Bochs

Sep 30 15:36:22 localhost kernel: EIP: 0060:[<c0590d0c>] EFLAGS: 00210297 CPU: 0

Sep 30 15:36:22 localhost kernel: EIP is at __btrfs_free_extent+0x526/0x6d4

Sep 30 15:36:22 localhost kernel: EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000000

Sep 30 15:36:22 localhost kernel: ESI: ebd7ded8 EDI: 078d0000 EBP: 0000000d ESP: e6583d5c

Sep 30 15:36:22 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

Sep 30 15:36:22 localhost kernel: CR0: 80050033 CR2: 0809301c CR3: 25bd2000 CR4: 000006c0

Sep 30 15:36:22 localhost kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000

Sep 30 15:36:22 localhost kernel: DR6: ffff0ff0 DR7: 00000400

Sep 30 15:36:22 localhost kernel: Process rm (pid: 16425, ti=e6582000 task=f4535b70 task.ti=e6582000)

Sep 30 15:36:22 localhost kernel: Stack:

Sep 30 15:36:22 localhost kernel: 00000001 00000000 f50ccbd0 00000000 0000000b 00000178 f55d3800 f528f120

Sep 30 15:36:22 localhost kernel: 00000001 00000000 00000d9c f4f70c00 00003800 000d078d 00a80000 00000010

Sep 30 15:36:22 localhost kernel: 00000000 0d078d00 a8000000 00001000 00000000 00000dc6 f04e6ea0 00000000

Sep 30 15:36:22 localhost kernel: Call Trace:

Sep 30 15:36:22 localhost kernel: [<c05954cb>] ? run_clustered_refs+0x740/0x800

Sep 30 15:36:22 localhost kernel: [<c09df0a0>] ? _raw_spin_lock+0xd/0x26

Sep 30 15:36:22 localhost kernel: [<c059579e>] ? btrfs_run_delayed_refs+0x213/0x332

Sep 30 15:36:22 localhost kernel: [<c0593e7f>] ? btrfs_trans_release_metadata+0xa0/0xb8

Sep 30 15:36:22 localhost kernel: [<c05a3e17>] ? __btrfs_end_transaction+0x68/0x1cc

Sep 30 15:36:22 localhost kernel: [<c05a3fab>] ? btrfs_end_transaction+0x9/0xb

Sep 30 15:36:22 localhost kernel: [<c05ab9ac>] ? btrfs_unlink+0x74/0x88

Sep 30 15:36:22 localhost kernel: [<c04c13c3>] ? vfs_unlink+0x59/0xb1

Sep 30 15:36:22 localhost kernel: [<c04c2c82>] ? do_unlinkat+0xa1/0x114

Sep 30 15:36:22 localhost kernel: [<c04e4251>] ? dnotify_flush+0x27/0xa0

Sep 30 15:36:22 localhost kernel: [<c04b74cb>] ? filp_close+0x52/0x58

Sep 30 15:36:22 localhost kernel: [<c09e3998>] ? sysenter_do_call+0x12/0x28

Sep 30 15:36:22 localhost kernel: Code: 24 28 89 f0 e8 73 7e 02 00 8b 8c 24 9c 00 00 00 89 cb c1 fb 1f 39 da 89 0c 24 89 5c 24 04 77 0d 72 09 3b 84 24 9c 00 00 00 73 02 <0f> 0b 89 c1 89 d3 2b 0c 24 1b 5c 24 04 89 0c 24 89 5c 24 04 09 

Sep 30 15:36:22 localhost kernel: EIP: [<c0590d0c>] __btrfs_free_extent+0x526/0x6d4 SS:ESP 0068:e6583d5c

Sep 30 15:36:22 localhost kernel: ---[ end trace 00fbf85d8d36bbc0 ]---
```

Last edited by LinuxTom on Wed Oct 02, 2013 7:14 am; edited 1 time in total

----------

## bell

Spricht was gegen einen aktuelleren Kernel? 3.5.7 ist wg. Sicherheitslücken gar nicht mehr in Portage. Mit neuerem Kernel ist das brtfs-Problem ggf. bereits behoben.

----------

## LinuxTom

Im 3.10er ist der BUG auch schon entdeckt worden. Ich muss erst diese Kernelversion ans laufen bringen und dann kann ich auf den nächsten (3.10er) updaten. Glücklicherweise ist das alles ein Atom-Client, dessen Pakete ich in einer KVM-VM auf meinem Host (Core-i7) vorbereite.

Edit:

Mein Eindruck. Wenn die Festplatte dem BTRFS zeitlich nicht uneingeschränkt zur Verfügung steht, kommt es zu dem Fehler. Bei mir immer bei großer Last in der QEMU-VM. Es ist zwar wesentlich Performanter als ReiserFS, doch nach dem UUPS ist das Dateisystem Schrott. Bei ReiserFS kann ich die Maschine durch Stresstest's nicht tot bekommen!

----------

## toralf

Probleme, Fehler etc. immer gleich an: linux-btrfs@vger.kernel.org

----------

## LinuxTom

Ich bin mir nicht mehr so sicher, ob wirklich das BTRFS dran Schuld ist. Jetzt kommt der u.g. Fehler (mit ReiserFS). Vielleicht ist es doch das qemu. Bei Qemu kann ich auch nicht das qcow2-Format einsetzen, weil dann die Ping-Zeiten des Gasten teilw. auf 50 Sekunden hoch gehen. Im Host ist leider kein Eintrag von qemu zu verzeichnen. Da scheint alles in Ordnung.

 *Quote:*   

> Oct  2 03:49:14 localhost kernel: BUG: unable to handle kernel paging request at 00047004
> 
> Oct  2 03:49:14 localhost kernel: IP: [<c04d4b0d>] sync_inodes_sb+0xc3/0x139
> 
> Oct  2 03:49:14 localhost kernel: *pde = 00000000 
> ...

 

----------

## LinuxTom

Hinweis: Ich habe schon

```
kernel.hung_task_timeout_secs=0
```

setzen müssen.

----------

