Bug 1214069 - Btrfs array is often unmounted right after mounting it
Summary: Btrfs array is often unmounted right after mounting it
Status: CLOSED DUPLICATE of bug 1226528
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-04-21 21:02 UTC by Basic Six
Modified: 2016-04-03 12:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-04-03 12:55:11 UTC
Type: Bug

Attachments (Terms of Use)

Description Basic Six 2015-04-21 21:02:35 UTC
Description of problem:

A btrfs array often cannot be mounted, it takes several attempts to actually mount it. It is unmounted right after mounting it and someone (who knows btrfs extremely well) said that systemd might be doing this unmount:
# mount /dev/sdc /data ; df -h /data ; sleep 5 ; df -h /data
Filesystem      Size  Used Avail Use% Mounted on
-                12G  2.4G  8.6G  22% /data
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/mapper/fedora--server_server-root   12G  2.4G  8.6G  22% /

Three lines were logged in dmesg, but no error:
[ 9063.251141] BTRFS info (device sdf): disk space caching is enabled
[ 9063.251148] BTRFS: has skinny extents
[ 9063.259716] SELinux: initialized (dev sdf, type btrfs), uses xattr

# btrfs fi show /dev/sdc
Label: 'DATA'  uuid: b0c9beef-6971-4da3-9697-6b0d3d75385e
	Total devices 4 FS bytes used 127.19GiB
	devid    1 size 2.73TiB used 64.53GiB path /dev/sdc
	devid    2 size 2.73TiB used 64.53GiB path /dev/sdd
	devid    3 size 2.73TiB used 64.53GiB path /dev/sde
	devid    4 size 2.73TiB used 64.53GiB path /dev/sdf

Btrfs v3.18.1

Version-Release number of selected component (if applicable):

# uname -sr
Linux 3.19.1-201.fc21.x86_64
# cat /etc/fedora-release 
Fedora release 21 (Twenty One)
# btrfs --version
Btrfs v3.18.1

How reproducible:

Mount on boot (fstab) stopped working, everything else behaves randomly. Manually mounting sometimes works, sometimes it's automatically unmounted within seconds.

Steps to Reproduce:
1. Boot, realize that btrfs array isn't mounted.
2. Mount manually, probably works, or not, who knows, unmount if it does.
3. Repeat step 2 three or four times, mount will automatically be unmounted as described above.

Actual results:

Btrfs array is automatically unmounted, right after mounting it.

Expected results:

Nothing should automatically unmount something that has just been mounted. And whatever program is unmounting should at least log something.

Additional info:

This worked before, with the same system. Also, when the volume is not randomly unmounted, it works fine (data can be accessed without a problem, all btrfs tools do their job, btrfs raid functionality works perfectly).

Comment 1 Basic Six 2015-04-21 21:11:29 UTC
This may be related. Those 5 lines appear in /var/log/messages:

Apr 21 23:01:38 server systemd: Job dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dsas\x2d0x0000000000000000\x2dlun\x2d0.device/start timed out.
Apr 21 23:01:38 server systemd: Timed out waiting for device dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dsas\x2d0x0000000000000000\x2dlun\x2d0.device.
Apr 21 23:01:38 server systemd: Dependency failed for /data.
Apr 21 23:01:38 server systemd: 
Apr 21 23:01:38 server systemd: 

This is how it should be mounted on boot, according to fstab:
/dev/disk/by-path/pci-0000:02:00.0-sas-0x0000000000000000-lun-0		/data		btrfs		defaults,compress=lzo,nofail 0 0

Is systemd thinking that something timed out and then unmounting it, even though the mount worked?

Comment 2 Basic Six 2015-05-04 16:49:29 UTC
Same error using Arch Linux on same system.

journalctl -xr:
systemd[1]: Unmounting /data...
-- Subject: Unit data.mount has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit data.mount has begun shutting down.
systemd[1]: Unit data.mount is bound to inactive unit. Stopping, too.
kernel: BTRFS: has skinny extents
kernel: BTRFS info (device sde): disk space caching is enabled

Comment 3 Basic Six 2015-05-04 19:09:49 UTC
Even manually adding TimeoutSec=0 to /run/systemd/generator/data.mount doesn't prevent systemd from timing out:

# time systemctl start data.mount ; df /data/
Warning: data.mount changed on disk. Run 'systemctl daemon-reload' to reload units.
A dependency job for data.mount failed. See 'journalctl -xe' for details.

real    1m0.103s
user    0m0.000s
sys     0m0.007s
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3       14510000 1536552  12213336  12% /

Comment 4 Basic Six 2015-05-04 19:11:01 UTC
Found a workaround: Remove it from fstab and mount it manually

Comment 5 Karel Zak 2015-08-18 08:19:53 UTC
Sounds like bug #1226528.

Comment 6 Fedora End Of Life 2015-11-04 10:50:06 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Basic Six 2015-11-20 09:37:58 UTC
Is this related to systemd issue 1788?

Comment 8 Zbigniew Jędrzejewski-Szmek 2016-04-03 12:55:11 UTC
This is very likely to be the same issue.

*** This bug has been marked as a duplicate of bug 1226528 ***

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