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).
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?
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
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% /
Found a workaround: Remove it from fstab and mount it manually
Sounds like bug #1226528.
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.
Is this related to systemd issue 1788? https://github.com/systemd/systemd/issues/1788
This is very likely to be the same issue. *** This bug has been marked as a duplicate of bug 1226528 ***