Bug 1413311 - forced readonly, fs/btrfs/delayed-inode.c:1170 __btrfs_run_delayed_items
Summary: forced readonly, fs/btrfs/delayed-inode.c:1170 __btrfs_run_delayed_items
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-14 19:34 UTC by Chris Murphy
Modified: 2019-01-09 12:54 UTC (History)
10 users (show)

Fixed In Version: kernel-4.9.7-201.fc25,kernel-4.9.7-101.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-25 22:30:22 UTC
Type: Bug


Attachments (Terms of Use)
dmesg (78.19 KB, text/plain)
2017-01-14 19:34 UTC, Chris Murphy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 191761 0 None None None Never

Description Chris Murphy 2017-01-14 19:34:59 UTC
Created attachment 1240812 [details]
dmesg

Description of problem:

Shortly after startup, file system is forced readonly.

Version-Release number of selected component (if applicable):
kernel-4.9.3-200.fc25.x86_64


How reproducible:
100% with a 4.9 or 4.10 kernel and certain subvolumes used as rootfs. I haven't figured out why some subvolumes are affected and others aren't.

Steps to Reproduce:
1. Boot system
2.
3.

Actual results:

Forced readonly during startup or shortly after logging in (time to forced readonly varies a bit)


Expected results:

Should remain writable.


Additional info:

It's definitely a regression, using git bisect the problematic commit is 6c6ef9f26e598fb977f60935e109cd5b266c941a. Filed an upstream bug and reported on the Btrfs list, filing this bug to track on Fedora.

Comment 1 Chris Murphy 2017-01-25 22:30:22 UTC
Upstream thread
https://www.spinics.net/lists/linux-btrfs/msg62368.html

Patch
https://www.spinics.net/lists/linux-btrfs/msg62362.html

Should make it into stable.

Comment 2 Ralf Ertzinger 2017-02-04 18:32:29 UTC
This has been closed, but is there any indication when this will get fixed in Fedora? As far as I can see this does not seem to have hit any upstream 4.9 release yet.

I have a number of machines that are affected by it that cannot be upgraded to 4.9. Reading the discussion on the mailing list this seems to be caused by snapshot dirs having the wrong xattr handlers (/var/lib/machines being a candidate as this gets created by default by the Fedora installer).

All machines I have that are affected used to have a subvolume for /var/lib/machines, but don't any more, I removed it long ago as I don't need it. Is there still some magic marker on the mount point directory that indicates it used to be a subvolume mount point? If so, is there a way to clean this?


Note You need to log in before you can comment on or make changes to this bug.