Are BTRFS mount options properly/fully displayed?
Screen:
CLI:
root@omv7vm:/# findmnt --real --type btrfs
TARGET SOURCE FSTYPE OPTIONS
/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-2 /dev/sdb btrfs rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/
root@omv7vm:/#Are BTRFS mount options properly/fully displayed?
This plugin is editing what is in the database which should match /etc/fstab. When you look at the output of findmnt, you get the options that "defaults" are translated to.
OK. If you didn't happen to know, or forgot, what the BTRFS default mount options were, at least adding a duplicate doesn't appear to cause a problem. As a NFS user yourself, what benefit do you see in including export bind mounts in the list?
Are you going to carry over the filesystem "TYPE" to the edit page, and add text pointing to the relevant FS man page ref?
Let me know thoughts about it.
Can you give an example where this plugin is useful for a common user? Maybe you're thinking about ZFS when writing this plugin or see other common use cases?
Can you give an example where this plugin is useful for a common user?
Number #1 reason should be evident by the "Remove quotas" button which has been causing very slow (20+ mins) config apply. But other users in the past have edited their mount options in the past for many reasons.
Maybe you're thinking about ZFS when writing this plugin or see other common use cases?
Nope. It only works with filesystems that use /etc/fstab. zfs, remote mount, mergerfs do not use /etc/fstab.
If you didn't happen to know, or forgot, what the BTRFS default mount options were, at least adding a duplicate doesn't appear to cause a problem
correct.
As a NFS user yourself, what benefit do you see in including export bind mounts in the list?
The plugin is literally a database editor. I didn't explicitly include nfs. It just has /etc/fstab entries and is in the database.
Are you going to carry over the filesystem "TYPE" to the edit page, and add text pointing to the relevant FS man page ref?
I added that hours ago and the package at the testing url already includes it.
Can you give an example where this plugin is useful for a common user? Maybe you're thinking about ZFS when writing this plugin or see other common use cases?
ZFS mount options are related to ZFS properties and never appear in /etc/fstab as previously stated. One "common use case" could be to change BTRFS mount to options to include "degraded" when dealing with disk failure on a BTRFS RAID1 profile.
I guess that's why I'm a little surprised by the purpose of this plugin. I have never bothered to research the different mounting options because I have never needed to, I suppose the reason is that I have never used BTRFS. Furthermore, one might think that if something similar is necessary it should be integrated into the management of OMV's BTRFS file systems.
As for the problem of eliminating quotas, apparently it is a recent problem. I trust this issue will be resolved shortly without the need for a plugin or changing filesystem mount options.
We are digressing, but I don't know of any plans to enhance BTRFS management in OMV such handling disk failure via the WebUI.
Yes, we digress. Nobody knows what's in someone else's head, in this case Volker. I'm just giving my opinion. OMV is a NAS, one of its main functions is to create and manage file systems. If that fails, everything else is of no importance. BTRFS is supposed to be fully integrated into OMV, or at least that's the intention if I'm not mistaken, so there should be an option in the OMV GUI for every configuration needed to manage that file system. If that is not the case at this time it can be said that the integration of BTRFS into OMV is not complete for now.
Well you could argue even the long standing MD RAID is not fully integrated as the WebUI offers no way to stop and assemble and inactive array.
That's right, mdadm is not fully integrated either. That is a deficiency in my opinion. That's why we keep seeing threads on the forum regarding array recoveries.
BTRFS is quirky, and replacing a failed disk via the WebUI alone would be a development challenge.
Nobody ever said it was easy. If it were easy, anyone could program it. 
I guess that's why I'm a little surprised by the purpose of this plugin.
Not every plugin is meant for noobs to use. It is nice for advanced users to have features once in a while. That is why it is a plugin. If you don't need it, don't install it. I'm a little disappointed that you seem to be so against this plugin. I actually told Volker I would've submitted a PR to add it to OMV but core changes require writing plugins in typescript and I don't have the time to learn all of that. And since 95% of users won't need it, it makes a better plugin than feature.
As for the problem of eliminating quotas, apparently it is a recent problem.
Nope. It has been a problem forever and people have had issues with aquota files since the beginning. The only way to remove these files is to remove the quota mount options which required database editing.
I trust this issue will be resolved shortly without the need for a plugin or changing filesystem mount options.
I wouldn't have wasted my time if that was the case. Quotas aren't the only reason this plugin is useful.
so there should be an option in the OMV GUI for every configuration needed to manage that file system. If that is not the case at this time it can be said that the integration of BTRFS into OMV is not complete for now.
I disagree with this statement. And the plugin was written primarily with ext4 and xfs in mind NOT btrfs. Will it work with btrfs? Yes.
I'm a little disappointed that you seem to be so against this plugin.
I'm sorry if it gives that impression, I didn't mean to sound like I'm against it. Quite the opposite, in reality I think that any function/complement that is added to OMV, even if not all users use it, is always positive. I was just trying to understand the usefulness of this plugin. From what you say, I suppose that not many people would use it, but still, if you think it is useful and since you have it written, I would add it to the repository so that anyone can use it. It will just be one more package that you will have to maintain. Although you already have a lot of work, we all know it, so it's up to you to do it or not.
If you need any kind of help to try this plugin, just say so, you know that I always help you in everything I can within my limitations. But to do tests I first have to understand what it is for
I understand this may seem unfair, but sometimes I can't help but compare OMV to DSM. You know I used DSM for a few years and it's still fresh in my mind. Don't tell me that you are just two developers here, I already know that, and that's why I say that comparison is unfair. It is inevitable that to do certain things in OMV the user must go to CLI. That number of times will depend on the degree of integration of the OMV GUI into the operating system.
Despite everything, you also know that I will always defend OMV against any other NAS system, but from time to time it is useful to look at each other's navel 
It allows you to do self-criticism that often helps to progress.
Why are the mount options gated to a DB?
Why are the mount options gated to a DB?
Everything in OMV depends on the database.
I suppose that not many people would use it,
I think every OMV user that isn't using quotas should use the "remove quotas" button on their filesystems. I would guess 95% of OMV users aren't using quotas. Most of these people won't use the editor part but that is why I added the buttons - to make it easy.
It will just be one more package that you will have to maintain. Although you already have a lot of work, we all know it, so it's up to you to do it or not.
You don't have to worry about that. I can manage what I do. This plugin is very simple. But sometimes, I just like to code something new and not work on things I don't like (like the zfs plugin). Bug fixing isn't interesting most of the time and I need to do other things to stay interested.
I understand this may seem unfair, but sometimes I can't help but compare OMV to DSM. You know I used DSM for a few years and it's still fresh in my mind. Don't tell me that you are just two developers here, I already know that, and that's why I say that comparison is unfair. It is inevitable that to do certain things in OMV the user must go to CLI. That number of times will depend on the degree of integration of the OMV GUI into the operating system.
OMV isn't supposed to be DSM. I personally don't like DSM. And I will tell you that only two people are working on this project in their spare time. That makes it near impossible to make a product that 650+ full time employees work on. How can that difference be ignored? I will keep saying it whether people like it or not.
Despite everything, you also know that I will always defend OMV against any other NAS system, but from time to time it is useful to look at each other's navel
I agree with that but that doesn't mean the goal of OMV or plugins should be to emulate DSM.
I am an engineer meaning I want to keep things simple and implement as much as possible while keeping the cost (not money) as low as possible. I think we manage to implement about 95% of features without having to use the CLI. The last 5% of these features just cannot be done with two people in the spare time. Even if someone implemented them for us, the maintenance would still be too much.
I think every OMV user that isn't using quotas should use the "remove quotas" button on their filesystems.
Why? While it is true that I have never configured quotas on a file system, in all the time I have used OMV I have never had a problem with that configuration existing. Using quotas doesn't make much sense on a home NAS. It may make more sense on a small business NAS. I'm sure it's a common case but in a small percentage of all OMV users. Despite everything, if this causes problems for many users as you say, I still think it should be resolved in the main project. But since Volker has not done it, I understand why you think it is useful to have a plugin that can do it.
But sometimes, I just like to code something new and not work on things I don't like (like the zfs plugin)
I understand perfectly, that happens to all of us in any aspect of our lives. I know perfectly well that you don't like the ZFS plugin, and I'm especially grateful that that plugin still exists.
That makes it near impossible to make a product that 650+ full time employees work on. How can that difference be ignored?
I have not ignored it, I already said it is an unfair, although inevitable, comparison, and I am sure that many people will continue to compare it. Don't see it as a problem, I would be proud if someone compared my work with the work of a team of 650 people.
I am an engineer meaning I want to keep things simple and implement as much as possible while keeping the cost (not money) as low as possible. I think we manage to implement about 95% of features without having to use the CLI. The last 5% of these features just cannot be done with two people in the spare time. Even if someone implemented them for us, the maintenance would still be too much.
I'm sure you know perfectly well how to find the balance between the work to be done in OMV and making OMV useful to the majority of people. If this were not the case, OMV would not survive.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
