#12788 closed bug (fixed)
BTRFS crash on mount
| Reported by: | destroyfx | Owned by: | korli |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | File Systems/Btrfs | Version: | R1/Development |
| Keywords: | gsoc2017 | Cc: | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Hi, I tried to mount a BTRFS partition to copy the syslog on it for another bug and it crashed hard. I will attach the "picture" of the panic log.
Attachments (4)
Change History (16)
by , 9 years ago
| Attachment: | IMG_20160518_101411.jpg added |
|---|
comment:1 by , 8 years ago
I'm affected by this bug too. I can't mount partitions on my hard disk or on a newly-formatted pendrive, so I guess that it's not caused by file system corruption. It doesn't matter whether I try to mount from command line, DriveSetup or Tracker.
comment:2 by , 8 years ago
FYI BTRFS on Haiku is read-only, no way to copy the syslog on it in Haiku itself.
comment:3 by , 8 years ago
| patch: | 0 → 1 |
|---|
follow-up: 5 comment:4 by , 8 years ago
The changes look good, but the commit message should give a little more details. Am I right that there are two ways to store the data stream (inline and out of band?) and we handled only one of them? This should be stored in the commit message so people looking at the git log can easily understand the changes.
by , 8 years ago
| Attachment: | 0001-Fix-ticket-12788.patch added |
|---|
update code for newer version of btrfs
comment:5 by , 8 years ago
Replying to pulkomandy:
The changes look good, but the commit message should give a little more details. Am I right that there are two ways to store the data stream (inline and out of band?) and we handled only one of them? This should be stored in the commit message so people looking at the git log can easily understand the changes.
Yeah, the data stream represents both the stream of the internal nodes (index) or the leaf nodes (entries), the node starts with a header[1]. Patch has been fixed.
[1]: https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Header
comment:7 by , 8 years ago
| Keywords: | gsoc2017 added; btrfs panic removed |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Applied in hrev51018. Thanks!
comment:8 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Sorry to reopen this. There is a bug in my patch, that when the stream is moved it also changes the size of item data. In the original version of the old patch, I use new variable to store the size of data before moving stream that why It worked successfully. I attach a new patch to fix this issue. Sorry again for the mistake.
by , 8 years ago
| Attachment: | misplace-size-of-item-data.patch added |
|---|
comment:10 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
comment:11 by , 6 years ago
This happens again in at least x86_64 Haiku in the revisions going back to at least 2 months ago. However, after a quick look (I may be wrong about this) I didn't find any btrfs driver file installed in x86_64. So haiku must be trying to mount the btrfs partition (I have 3 other disks with btrfs partitions on this machine, one is the root of a Linux install, the other is a hardware RAID1 array, I tried the the Linux install to go get some file) with some other Linux FS and then it KDLs.
crash "log"