Re: BTRFS settings for media storage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 29, 2021 at 7:17 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
>
> So after about 12 forced power offs while copying data (via rsync) this is the only output from dmesg:
>
> # dmesg | grep -i btrfs
> [    0.776375] Btrfs loaded, crc32c=crc32c-generic, zoned=yes
> [    5.497241] BTRFS: device fsid d9a2a011-77a2-43be-acd1-c9093d32125b devid 1 transid 389 /dev/sdc scanned by systemd-udevd (732)
> [    5.521210] BTRFS: device fsid d9a2a011-77a2-43be-acd1-c9093d32125b devid 2 transid 389 /dev/sdd scanned by systemd-udevd (743)
> [    6.743097] BTRFS info (device sdc): disk space caching is enabled
> [    6.743100] BTRFS info (device sdc): has skinny extents


This is the usual case. Btrfs kernel code reads the super which is
only pointing to a completely consistent set of btrees. A variation on
this is if a process making use of fsync was interrupted by the crash,
you might also see this line:

BTRFS info (device vda3): start tree-log replay

That also is normal and fine. No fsck required, nor scrub required.
You don't need to do anything. If the hardware is doing the correct
thing, you can hit it with power failures while writing all day long
and the file system will never care about it. This is by design. But
also Btrfs developers wrote dm-log-writes expressly for power failure
testing, and is now used in xfstests for regression testing all the
common file systems in the kernel. So there's quite a lot of certainty
that write ordering is what it should be.


> [   61.730008] BTRFS info (device sdc): the free space cache file (1833981444096) is invalid, skip it
>
> Should I worry about the last line?

Nope. It's just gone stale, because it didn't get updated prior to the
power fail. They rebuild quickly on their own. And it's not critical
metadata, just an optimization.

(This is a reference to the v1 space cache which exist as hidden files
in data block groups. The stable and soon to be default v2 space cache
tree moves this to metadata block groups and it's quite a lot more
resilient and more performant for very busy and larger file systems.
Anyone can switch to v2 by doing a one time mount with the mount
option space_cache=v2. Currently it needs to be a new mount, there's a
bug that causes it to claim it's using v2 but it's not actually
setting up the v2 tree. Once this mount option is used, a feature flag
is set, and it'll always be used from that point on. It's not
something that goes in fstab. Use it one time and forget about it.
Sorta like a file system upgrade if you will. Note that large file
systems might see a long first time mount with this option being
initially set. I've anecdotally heard of it taking hours for a 40T
file system, because the whole tree must be created and written before
the mount can complete. For me on a full 1T file system it took
*maybe* 1 minute.)

-- 
Chris Murphy
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux