On 03/05/2023 21:56, Nicholas D Steeves wrote:
> Hi,
>
> Graham Cobb writes:
>
>> The new checks at mount time cause mount times for large filesystems to be
>> much
>> longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
>>
More recent kernels have definitely improved the
Hi,
Graham Cobb writes:
> The new checks at mount time cause mount times for large filesystems to be
> much
> longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
>
I'm curious how "aged" the fs is, (largest generation from btrfs subvol
list), how many subvolumes, if qgroups
Package: btrfs-progs
Version: 5.7-1
Followup-For: Bug #955413
Thanks for looking into it. I agree with your analysis but the issue is real.
I think the long mount times tend to occur when there are large numbers of
subvolumes and other large trees.
Although the problem is not fixable in
(Sorry for the delay -- I investigated the cause but somehow failed to post
here. Recently someone on the mailing list reported it also, with same
conclusion.)
On Tue, Mar 31, 2020 at 01:20:48PM +0100, Graham Cobb wrote:
> Package: btrfs-progs
> Version: 5.3.1-1
> The new checks at mount time
We see that, too, at the institute... any larger (few TB) filesystems
in /etc/fstab make systemd cause the system to fail at boot... leaving
it a state with no remote resuce (ssh) being possible.
Since such filesystems would mount just fine... I would rather say that
this functionality is a
Package: btrfs-progs
Version: 5.3.1-1
Severity: minor
The new checks at mount time cause mount times for large filesystems to be much
longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
Unfortunately, this is longer than the default systemd mount timer and systemd
assumes the
6 matches
Mail list logo
