Btrfs devel - Nov 2013 - Odp: Btrfs might be gradually slowing the boot process

Silly me; I am using a fully updated Arch Linux x64 (3.11.6 kernel), I have a
single HDD with a root and home subvolume under the main btrfs subvolume and I
am not using any "exotic" settings. This is a most regular desktop.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Nov 08, 2013 at 08:10:00PM +0100, yzb3@wp.pl
wrote:
> Silly me; I am using a fully updated Arch Linux x64 (3.11.6 kernel), I have
a single HDD with a root and home subvolume under the main btrfs subvolume and I
am not using any "exotic" settings. This is a most regular desktop.
   Can you give exactly the mount options you are using? For a root
filesystem, these are probably in your bootloader configuration rather
than fstab: rootflags=... on your kernel command line.

   Also, just as a confirmation, the same settings from /proc/mounts
once the machine''s booted.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- People are too unreliable to be replaced by machines. ---

On Friday, November 08, 2013 07:35:18 PM yzb3@wp.pl
wrote:
> Hello,
> 
> I recently noticed that my boot has become slower - it took around 29s,
> while at the beginning it was ~6s. I thought it was an issue with systemd,
> because it failed to properly indicate at which stage the slowdown occurred
> and how long it took. I rolled back to a pretty fresh root subvolume and
> the boot was fast again. However, after several reboots it started lagging
> again (10s? preposterous!). I decided to try the *clear_cache* mount
> option; it was only a guess, but it did speed the boot to the proper ~6s.
> 
> The question is - why? My filesystem is really small - I see no reason 
for a
> 5x boot slowdown. Is this a known issue? I will be glad to give any
> additional details about my fs.
>> Have you tried defragmenting everything, including directory objects?
despite
>> of small amount of data, it could be massively fragmented, slowing down
>> everything.
>> 
>> HTH
Would the problem have disappeared by just clearing the cache if there were so
many extents? I remember that the defrag is not recursive - can you tell me how
to make it process everything? Or to just list the number of extents? In the
meantime this is the output of btrfs fi df /:

Data: total=49.01GB, used=48.53GB
System, DUP: total=8.00MB, used=12.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.00GB, used=515.11MB
Metadata: total=8.00MB, used=0.00

and df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       932G   50G  881G   6% /
dev             3,9G     0  3,9G   0% /dev
run             3,9G  560K  3,9G   1% /run
tmpfs           3,9G  136K  3,9G   1% /dev/shm
tmpfs           3,9G     0  3,9G   0% /sys/fs/cgroup
tmpfs           3,9G  8,0K  3,9G   1% /tmp
/dev/sda2       932G   50G  881G   6% /home


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html