Hi Andy! Sorry for the delay, reply follows inline.
andy <and...@diatribes.org> writes: > thanks for the feedback... some comments inline. i must stress that > while i am a multi-year user of btrfs i do not read the linux-btrfs > mailing list and my opinions should be given appropriate weight. Thank you for your willingness to share your experience along with what you'd like to see. After all, what's the point if real-world users aren't accommodated? :) > On Sat, 2023-01-14 at 21:47 -0500, Nicholas D Steeves wrote: [snip] >> From what I've been able to gather, metadata balances have been >> considered to be actively harmful for some time; This is mostly at >> the level of tribal knowledge on the linux-btrfs mailing list. It's >> also the case that empty block groups are now automatically reclaimed >> by the kernel, so a periodic balance only seems to be useful in >> space-constrained situations where a lot of [meta]data churn occurs. > > regarding balance recommendations, my initial thought would be to make > the language in the README.Debian stronger. Would this be enough to guard naive users from potential data loss? You know, the people who read docs as an afterthought, or the "it will be fine; it won't happen to me" crowd... At the same time, I worry that there might be a social cost to using stronger language (it could demotivate developers or scare people off of trying btrfs). What do you think? I agree, the docs should be updated; however, I'll also need to be prepared to provide citations and reasoning. To be honest, I'm trusting a recurring upstream statements on the question of metadata rebalancing. > i had read that "Some advocate not running it at all" but to me that > implies "may be unnecessary" rather than "may be actively harmful." > on the basis of the latter i am certainly considering setting the > balance.timer back to disabled. Btw, I'm curious to learn why you've enabled balancing! The "may be actively harmful" bit is tricky, because Btrfs gets way too complicated way too fast... My hope to put in place safe defaults that work for most people, that don't bait users/sysadmins into taking on risk, and that are good enough for the general case. Of course you know that a solid enough replication and backup strategy makes it ok to take risks for optimisation, but that's the "educated/experienced sysadmin" class of cases ;) If rebalancing does something like keeping database performance from degrading, then it would be worth documenting this somewhere, along with the fact that several core devs upstream have written statements to the effect of this: never balance metadata, unless necessary. Rebalancing to a new profile counts as "necessary", obviously, and the only other corner case I'm aware is noted two paragraphs below. > alternatively/additionally are there default options that might make > it safe(r)? I believe that [metadata] balancing should probably be disabled in upstream btrfsmaintenance. If I remember correctly, it's enabled by default because upstream targets 10year LTS releases such as SUSE's 11 series, which uses linux 3.0.76, where the harm reduction of metadata balancing is significant enough to make the risk worthwhile on server-grade hardware. > e.g., Marc MERLIN's > `btrfs-scrub`[1] (which i used previously) suggested that "a null > [metadata] rebalance should help corner cases." > Has that corner case existed since linux-3.18? https://btrfs.wiki.kernel.org/index.php/Balance_Filters Or are you referring to cleaning up inefficient use of metadata after a batch deletion of thousands of snapshots or subvolumes (all at once)? > from my pov i'd still like to see the values harmonized. i originally > noticed the inconsistency because what i believed was the default > setting was creating a seemingly unnecessary systemd override file. Sorry, what is this "unnecessary systemd override file"? > this became a nagging question to resolve :) if the (informed) user > has chosen to enable the btrfs-balance.timer then i would say harmonize > the value at "monthly" (1/4 the opportunity for issues). > People are funny, because when you write or say "This is bad, you must never do this, but if you do this, here is how to do it" the message that is understood is "here is how to do it" ;) >> Thus, if I do anything, I'm inclined to set the period for balance to >> "none" everywhere. > > given that one already needs to manually enable the service via > `systemctl enable btrfs-balance.timer` i don't think it's necessary to > set the default value to "none." this would result in the (imho) > counter-intuitive behavior of enabling something only to have it do > nothing. although an add'l comment re: the potential for harm in > `/etc/default/btrfs` that one would hopefully see when changing the > value from "none" to e.g., "monthly" may be the best way to ensure that > they are an informed user. so i could go either way on that. > Good point, and yes, I agree that two knobs seems silly; however, there is already precedent for this with '"BTRFS_TRIM_PERIOD="none"'. As there doesn't seem to be any interest in #887461, I'm wondering if might be time to follow the consensus of the General Resolution in favour of systemd, and soon start shipping systemd timers in an enabled state, and disable everything in the config file, but provide suggested values... >> Also, what do you think about enabling the systemd patch watcher, so >> that the timers are updated automatically when >> /etc/default/btrfsmaintenance is modified? > > as a sysadmin the steps of modifying a file and then running a command > for it to take effect is a normal part of my workflow. so i'm fine > leaving it disabled by default. other users might feel differently. > I guess keeping it the way it is right now can act as a kind of safety gate, so if I install the timers in an enabled state, but disabled, then only users who read the docs will be able to update those times. Maybe that, plus some "NOT RECOMMENDED" comments in the config file would be a nice compromise? Regards, Nicholas
signature.asc
Description: PGP signature
