Boot slow, "scanning for btrfs filesystems" takes 100 seconds

[Dan Kegel]

I installed 14.10 and used btrfs for /home. Later, I did a clean install of 15.04, using the same /home partition.
Ever since then, boots have been agonizingly slow; all the delay appears to be while the message
"scanning for btrfs filesystems" is diplayed early in boot.

The system is an i7 with one disk:

root@i7:~# fdisk /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00007f84

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 117186559 117184512 55.9G 83 Linux
/dev/sda2 117186560 234373119 117186560 55.9G 83 Linux
/dev/sda3 234375166 1953523711 1719148546 819.8G 5 Extended
/dev/sda5 234375168 273434623 39059456 18.6G 82 Linux swap / Solaris
/dev/sda6 273436672 1953523711 1680087040 801.1G 83 Linux

root@i7:~# df -T | grep sd
/dev/sda2 ext4 57542652 10103624 44492980 19% /
/dev/sda6 btrfs 840043520 172076728 665321064 21% /home

I'll attach a bootchart, but I suspect the btrfs delay happens before the bootchart starts?

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-16-generic 3.19.0-16.16
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: dank 2176 F.... pulseaudio
 /dev/snd/controlC0: dank 2176 F.... pulseaudio
CurrentDesktop: Unity
Date: Sun May 31 08:53:37 2015
HibernationDevice: RESUME=UUID=417f2bba-dea3-496b-ad18-702d4dc6f223
InstallationDate: Installed on 2015-05-16 (14 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.

 lxcbr0 no wireless extensions.
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic root=UUID=270a0d36-9ed9-4e58-b909-175db447838d ro quiet splash init=/lib/systemd/systemd-bootchart
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-16-generic N/A
 linux-backports-modules-3.19.0-16-generic N/A
 linux-firmware 1.143
RfKill:

SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/16/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P2.50
dmi.board.name: X58 Extreme
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP2.50:bd08/16/2010:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnX58Extreme:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc6-unstable/

[rrva (ragnar-rova)]

Editing /usr/share/initramfs-tools/scripts/local-premount/btrfs to remove the scan speeds up boots for me on 4.0.0-4-generic wily. That'll stop you from being able to mount a multi-device filesystem as root, which I do not need.

[rrva (ragnar-rova)]

and then doing update-initramfs -u of course

[rrva (ragnar-rova)]

Hold on, removing the scan was not a complete solution. I still have slow boots, caused by something else.

[rrva (ragnar-rova)]

It definitely changed in boot time by me adding a btrfs-formatted block device to the system (/dev/sdb, without a partition table)

[rrva (ragnar-rova)]

Sorry for noise. Disabling btrfs scan did improve boot time, i just had other (DHCP) issues also.

[bobhurt (bob-bobhurt)]

I have an I7 with 12G and SSD base drive, with UBUNTU alongside Win 8. UBUNTU 15.04 takes 100 seconds to boot on that system. Win 8 boots in about 20 seconds. 14.10 booted MUCH faster. I haven't measured the difference, but gut feel tells me the developers did something stupid.

USER EXPERIENCE, Canonical. TAKE A LESSON FROM APPLE . USER EXPERIENCE COMES FIRST.

We want fast booting and a smooth, fast, hiccup-free, gorgeous, intuitive user interface. No bright ideas like common core or new math or political correctness. Just smooth, fast, clean booting and UI. That and staying relatively virus free will win the world's devotion.

[Dan Kegel (dank)]

Upgrading to ubuntu 15.10 magically improved things.

It's possible it was running fsck, or something.

I would like to close this as fixed.

[Dan Kegel (dank)]

This is back with 16.04, and affects multiple systems.

[BronsonMathews (bronsonmathews)]

yep, getting this on 16.04 also!!

[Fredrik Blomqvist (fgblomqvist)]

I can confirm that this is still the case on 16.04.
I moved my home folder to a btrfs partition and now it takes my computer an extra minute or so to boot (during which it's just sitting on a Ubuntu-purple blank screen, no indicator). Time to change the partition to ext4...

[Stu (stu-axon)]

I'm not using btrfs and get this on 16.04

[m1st0 (m1st0)]

I saw this as well on 18.04 during boot. Since

    /usr/share/initramfs-tools/scripts/local-premount/btrfs

calls for the scan, you can workaround this issue by dealing with that file. Since I wasn't using BTRFS regularly, I purged the file through

    sudo apt purge btrfs-progs

[jvandenbroek (jvandenbroek)]

Same on 18.04, but I'm using btrfs for both root and home, so can't purge the package.. Any idea? It hangs for about 30 sec before continuing, annoying to have this slow boots on a SSD..

[g_kos (kos-4)]

I am experiencing the same issue on ubuntu 18.04.
root and home are both on btrfs, so purging the btrfs package is not an option.
During the boot the system stops and waits following the message "scanning for btrfs..."

[jvandenbroek (jvandenbroek)]

I thought it hang on 'scanning for btrfs', but it was actually the resume service/method causing the delay. In my case the resume/swap device is on a LV, could solve it by using this instruction (first method): https://askubuntu.com/questions/1037457/slow-boot-with-ssd-and-lvm-on-new-install-of-18-04

So it seems that if the swap is a LV, UUID no longer works (which did work fine on 17.10) and you now need to specify the mapper path instead.

[karlsebal (karlsebal)]

Thanks, jvandenbroek – Method 2 fixed it. Although naming a resume device leads to the same behaviour: when running `update-initramfs` it complains about "target cryptswap1 has a random key, skipped
" and boot process is hanging again.

[Dan Kegel (dank)]

https://askubuntu.com/questions/836105/ubuntu-16-04-takes-long-time-to-boot-using-btrfs-and-persistent-logs suggests disabling COW on the systemd journal directory may help.

Avoiding / as btrfs, and using it just for e.g. /var/lib/lxd, may be an option for some people.

[Simon Iremonger (ubuntu-iremonger)]

This issue, or variant thereof, has been observed on Ubuntu 20.04 and Linux Mint 20.
I'm not 100% sure yet but it SEEMS to be affecting systems with a floppy drive.

Can end up with bootup-messages:-

[timestamp] Btrfs loaded, crc32c=crc32c-generic
Scanning for Btrfs filesystems
[timestamp] floppy0: floppy_queue_rq: timeout handler died. old request running

removing 'btrfs-progs' (which then removes from initrd) works around the issue reliably.
I need to double-check, i think kernel command line modprobe.blacklist=floppy can also workaround issue.
Last I checked, I didn't find this to be specific to a particular kernel/series.

Certainly experienced this on totally different hardwre, e.g. an intel core-2-duo in compaq Dx2300, but also on a completely different HP motherboard AMD64 machine/chipset. From what I can see this is not particular hardware specific either!.

[Simon Iremonger (ubuntu-iremonger)]

Oh, and to be clear, both said machines floppy working properly! Not just faulty drive giving timeouts.

[Simon Iremonger (ubuntu-iremonger)]

I can further confirm that taking out the btrfs scan in /usr/share/initramfs-tools/scripts/local-premount/btrfs fixes the intermittent boot issue for me. For me, this causes some deadlock between btfs scan and floppy driver and requires reboot, not just slow!. This may be a case of 'separate bug needed' .....

[Simon Iremonger (ubuntu-iremonger)]

OK Turns out my btrfs+floppy bug is indeed a kernel floppy matter, and the btrfs scan just 'triggers' the fault.

The new kernel floppy maintainer says:-
This patch should fix the problem:
263c61581a38 ("block/floppy: fix contended case in floppy_queue_rq()")
The commit id in stable tree is 29ed45653bec.

> ubuntu kernel 5.4.0-42-generic
I think that these versions don't contain the fix. The fix is in the
5.4 kernel since 5.4.47 version.

SO, looks like my related comment is a red-herring and (should) be fixed by routine updates to 5.4.0 ubuntu kernel updates!.

[Simon Iremonger (ubuntu-iremonger)]

I can confirm my specific failure was fixed with kernel 5.4.0-48 ...

Question for original reporter Dan -- is this issue (slow btrfs scanning) still occuring for you? Now fixed?