-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mounting takes a while #777
Comments
Mount with -o verbose, that will tell us which recovery pass is causing problems |
Here you go, hope this helps. |
dmesg shows the filesystem is mounted 7.7s into the boot. |
No, this is a bcachefs bug - if you look at the SRCU warnings, the issue is that the first inode allocations take a long time because they have to scan. We still don't have a real inode allocator; I was planning on adding a free inodes btree but I have a better idea now. |
Is this addressed by commit df245c0 ? |
Yes, but the bigger one is c6b74e6 ("bcachefs: bcachefs_metadata_version_disk_accounting_big_endian") |
I decided to take the plunge on bcachefs recently, for ease of disk management and for fast data caching.
I've got a fairly modest amount of data, 723GB with a pair of SATA HDDs as the backing store and a SATA SSD as the promote target.
I noticed the boot times were a bit slower than my original ext4 root on the SSD. Since then I've noticed my boot times steadily getting longer and longer. With systemd reporting a mount time of 38s at the moment.
I'm wondering what I can do to keep the mount time down. Is this sort of time expected?
systemd-analyze plot
Drives
Kernel version
6.11.6-arch1-1 #1 SMP PREEMPT_DYNAMIC
mount info
options
bcachefs fs usage /
The text was updated successfully, but these errors were encountered: