Austin S. Hemmelgarn posted on Wed, 10 Jan 2018 12:01:42 -0500 as excerpted: >> - Some experienced users say that, to resolve a problem with DoUS, they >> would rather recreate the filesystem than run balance. > This is kind of independent of BTRFS. A lot of seasoned system > administrators are going to be more likely to just rebuild a broken > filesystem from scratch if possible than repair it simply because it's > more reliable and generally guaranteed to fix the issue. It largely > comes down to the mentality of the individual, and how confident they > are that they can fix a problem in a reasonable amount of time without > causing damage elsewhere. Specific to this one... I'm known around here for harping on the backup point (hold on, I'll explain how that ties in). A/the sysadmin's first rule of backups: The (true) value of your data is defined not by any arbitrary claims, but by how many backups of that data you consider it worth having. No backups defines the data as of only trivial value, worth less than the time/ trouble/resources necessary to make that backup. It therefore follows that in the event of data mishap, a sysadmin can always rest happy, because regardless of what might have been lost, what actions defined as of *MOST* value, either the data if it was backed up, or the time/trouble/resources that would have otherwise gone into that backup if not, was *ALWAYS* saved. Understanding that puts an entirely different spin on backups and data mishaps, taking a lot of the pressure off when things /do/ go wrong, because one understands that the /true/ value of that data was defined long before, and now we're simply dealing with the results of our decision to define it that way, only playing out the story we setup for ourselves long before. But how does that apply to the current discussion? Simply this way: For someone understanding the above, repair is never a huge problem or priority, because the data was either of such trivial value as to make it no big deal, or there were backups, thus making this particular instance of the data, and the necessity of repair, no big deal. Once /that/ is understood, the question of repair vs. rebuild from scratch (or even simply fail-over to the hot-spare and send the old filesystem component devices to be tested for reuse or recycle) becomes purely one of efficiency, and the answer ends up being pretty predictable, because rebuild from scratch and restore from backup should be near 100% reliable on a reasonable/predictable time frame, vs. /attempting/ a repair with unknown likelihood of success and a much /less/ predictable time frame, especially since there's a non-trivial chance one will have to fall back to the rebuild from scratch and backups method anyway, after repair attempts fail. Once one is thinking in those terms and already has backups accordingly, even for home or other one-off systems where actual formatting and restore from backups is going to be manual and thus will take longer than a trivial fix, the practical limits on the extents to which one is willing to go to get a fix are pretty narrow, and while one might try a couple fixes if they're easy and quick enough, beyond that it very quickly becomes restore from backups time if the data was considered valuable enough to be worth making them, or simply throw it away and start over if the data wasn't considered valuable enough to be worth making a backup in the first place. So it's really independent of btrfs and not reflective on the reliability of balance, etc, at all. It's simply a reflection of understanding the realities of possible repair... or not and having to replace anyway... without a good estimate on the time required either way... vs. a (near) 100% guaranteed fix and back in business, in a relatively tightly predictable timeframe. Couple that with the possibility that a repair may leave other problems latent and ready to be exposed later, while starting over from scratch gives you a "clean starting point", and it's pretty much a no-brainer, regardless of the filesystem... or whatever else (hardware, software layers other than the filesystem) may be in use. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
