BTRFS is a new world for me. Last weekend I decided to give it a try and I reinstalled Garuda with BTRFS. In another thread I read that it is not a good idea to reboot or shutdown the system when a BTRFS maintanance is running. The BTRFS Assistant will do a maintanance once a week/month. So I wonder if there is any prevention that makes it impossible to reboot or shutdown during a running maintanance or if there will be a notification at least?
I would like to know if there any merit to this, or does one actually have to manually run it / schedule it? I can't see it being setup out of the gate to run without informing the user, or at least informing the user they can't restart or logout if it is running and they try to do either.
On a side note one never restarts or even logs off the system during any kind of disk specific operations.
Why would that be needed? Btrfs scrub and balance shouldn't cause issues even if the system is restarted while they are running.
Ok, thak you for your help!
In my opinion, there are really only a couple of things that are truly unstable in Btrfs
- Raid 5/6 configurations
- Running with quotas enabled
Most of the rest of it is FUD/misunderstandings.
I also use zfs pretty heavily and you can't really look at btrfs through the lens of zfs. While they do similar things in some cases, they are fundamentally and architecturally different. You can't treat btrfs like zfs or vice-versa.
I think it would be hard to argue against the fact that zfs is more reliable and has more features. That being said, that doesn't make btrfs "bad".
It almost shocking how much blatant misinformation has been presented in this topic.
Is it the case (misinformation) with
autodefrag that shouldn't be used?
Debian btrfs Recommendations
I wouldn't use it personally because in most use cases I don't think it is needed and it isn't worth the performance hit.
That being said, other than performance problems, are there system stability issues caused by it?
I understand your point now. You said "truly unstable in Btrfs". That doesn't mean the other features/options are bad or good, it just means they are not "truly unstable".
Good point, tnx!
There is currently no stable/perfect CoW filesystems. You can see there are many light and heavy bugs/defects that will take longer to eventually stability.
Nevertheless, both have the useful functions better than other non-CoW file system.
I must admit that I was leary of using BTRFS before I switched to Garuda. Reading about the problems some users experienced with it in the past made me a little gun shy on using it. That was several years back and I think BTRFS has come a long ways since back then. Other than having to disable BTRFS quotas I have found the file system to be very trouble free.
I think quotas are disabled by default in Garuda, if I'm correct?
If it is disabled by default that would be a new implementation. There have been discussions about making that the default, but I'm unsure if it was ever implemented.
Many of those discussions with the devs take place on Telegram, and I could have missed that decision. I'm too old to take up chat type platforms now, too set in my ways. I'll leave chat apps to the teeny boppers.
Interesting... last and only time I checked on my quotas, this Winter, it was disabled and I explicitely never disabled them (nor enabled them). Now we talk about this I am curious and will double-check tonight. loll
I am still running my original install of KDE Light from when I first started using Garuda, so I sometimes miss changes that have taken place recently. I do not test out new versions regularly as I spend so much time customizing my system I rarely install new OS's.
If the change did take place, it probably would have coincided with the adoption of snapper. Before that it was semi required for timeshift to operate properly.
Quota is disabled by default since we switched to snapper.
Quota was enabled by timeshift
Thanks for that update @librewish. I'm often the last one to catch changes as I don't follow the dev chat on Telegram.
I think what should be obvious from my last post, is that if BTRFS is unstable why is my original Garuda install still up and running so well almost 2 years later. I have no reservations about BTRFS's stability now, as I have found zero issues with BTRFS & COW file system.
It was a great discussion so far.
Each one shared their experience and this is of the greatest value IMHO.
There is no real knowledge unless it is from experience. (wise words by me )
Theory is not knowledge, only speculations.
Not everyone has the same experience, thus plenty of people sharing personal experience is great!
Thanks to all!
Reading your comments I see that you consider that BTRFS is not ready for production, but I have asked SysAdmins of years of experience and they use it for production already years in fact in a conference titled: Make your machine enigma and one of the conditions is to use BTRFS for being very dynamic and versatile, this file system is very robust and as a conclusion that I drew from doing some tests is that if I use it for O.S. to store files is like using a tank to kill a fly. We should hack it to take an extra advantage and that is why I like Garuda because by default it suggests that you put it in BTRFS and with its tools to take Snapshots automatically and simplifies me a lot in the configuration.
I like that Garuda uses BTRFS as file manager by default, but it will depend on the maintainers how much more they can hack it because so far they make it very easy to manage the system but for example you could do some hacks like for example, with a single disk or storage unit you could make a RAID 1 to have better file backup, it sounds crazy but it is not exactly a RAID 1 but a hack that can be done BTRFS to create subvolumes and configure it as RAID 1.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.