Opened 3 years ago

Closed 2 years ago

Last modified 12 months ago

#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:
Has a Patch: yes 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)

IMG_20160518_101411.jpg (2.5 MB ) - added by destroyfx 3 years ago.
crash "log"
20160615_215952.jpg (1.5 MB ) - added by przemub 3 years ago.
Backtrace
0001-Fix-ticket-12788.patch (1.8 KB ) - added by hyche 3 years ago.
update code for newer version of btrfs
misplace-size-of-item-data.patch (3.3 KB ) - added by hyche 2 years ago.

Change History (16)

by destroyfx, 3 years ago

Attachment: IMG_20160518_101411.jpg added

crash "log"

comment:1 by przemub, 3 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.

by przemub, 3 years ago

Attachment: 20160615_215952.jpg added

Backtrace

comment:2 by korli, 3 years ago

FYI BTRFS on Haiku is read-only, no way to copy the syslog on it in Haiku itself.

comment:3 by hyche, 3 years ago

Has a Patch: set

comment:4 by pulkomandy, 3 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 hyche, 3 years ago

Attachment: 0001-Fix-ticket-12788.patch added

update code for newer version of btrfs

in reply to:  4 comment:5 by hyche, 3 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:6 by korli, 3 years ago

LGTM

comment:7 by pulkomandy, 3 years ago

Keywords: gsoc2017 added; btrfs panic removed
Resolution: fixed
Status: newclosed

Applied in hrev51018. Thanks!

comment:8 by hyche, 2 years ago

Resolution: fixed
Status: closedreopened

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 hyche, 2 years ago

comment:9 by pulkomandy, 2 years ago

Applied in hrev51063. Thanks again!

comment:10 by pulkomandy, 2 years ago

Resolution: fixed
Status: reopenedclosed

comment:11 by dpirate, 12 months 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 two are a hardware RAID1 array, I tried mounting the Linux install to go get some file) with some other Linux FS and then it KDLs.

Last edited 12 months ago by dpirate (previous) (diff)

comment:12 by waddlesplash, 12 months ago

Please open a new ticket with the panic message.

Note: See TracTickets for help on using tickets.