On 9/12/24 16:52, Neal Gompa wrote:
On Thu, Sep 12, 2024 at 8:02 PM Przemek Klosowski wrote:
On 9/12/24 12:12, Aoife Moloney wrote:
Anaconda will replace root and should have a possibility to
preserve /home with user data.
This is great, but in a default setup /home is just a btrfs subvolume.
Would this method be able to preserve /home while recreating the system
part, in the 2-subvolume scenario?
"2-subvolume scenario"? We already split root and home into separate
subvolumes, and Cloud images even split var into its own subvolume
too.
Sorry, I wasn't clear. I thought that if anaconda is told to
reuse/rebuild the btrfs fs it will kill both / and /home. Unless there's
a way to delete the / subvolume without deleting /home?
A related question: when rebuilding because of a failed btrfs, the
recommendation is to reinstall on a brand new filesystem, and restore
/home from backup. If anaconda could easily preserve /home, maybe the
default should be switched back to separate / and /home, so that when /
is damaged but /home isn't the system rebuild is easier?
It doesn't really change much when everything is on the same disk, and
just reintroduces the space contention issues we intentionally wanted
to eliminate. As it stands, the subvolumes are separate hierarchies
and can be independently managed today, but share the same pool of
disk space
So I'm assuming that the disk hardware is fine.
You're right, splitting / and /home is a stupid idea for the reasons you
mentioned (and I complained about them for years). However, btrfs
tooling arguably doesn't treat subvolumes separately enough; fs errors
anywhere seem to affect the entire btrfs volume, across all the subvolumes.
I think at this point btrfs itself is reliable in normal operation, but
it's fragile with respect to e.g. memory error-induced errors.
Anecdotally, I had a system that went R/O with one checksum error. It
was most likely due to a DRAM error, because subsequent BIOS check
detected some and had to recalibrate the memory controller. The fs
mounted readonly and showed an existing filesystem (allowing for extra
shelf-and-suspenders backup, etc); however, attempts to repair it
resulted in cascading errors and unreadable fs. In this scenario, it was
annoying that I couldn't tear down and rebuild only the one subvolume
that had errors. Admittedly, maybe it was possible and I just didn't
know how to do it.
All this is of course out of scope for this proposal, but I thought it'd
be good to write it down because btrfs is very appealing and yet
imperfect in important ways. I can't decide if the take-home conclusion
is "only use ECC memory" or "btrfs tooling needs to better deal with
errors".
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
