Q: How to know and manage who (users / programs) is actively using MergerFS ?

[HaroPo]

Hi,
I am trying furthermore MergerFS on a little DIY NAS wiht 4 SSD drives having each a directory called 'Backups' that I want to combine to see and access all the data stored there.
So far, MergerFs does its job fine. :-D

I use SSHFS on the client computers to access the NAS mount point for MergerFS.

I wanted to clean some mess due to duplicate folders created by MergerFS on the 4 SSD while I want only one copy of the folder on one SSD drive (So, I sould have accessed the drive independently, I accessed via MergerFS : My mistake...)

So, I wanted to use 'umount' like when there is Nobody using the NAS during my setup work.
Problem, I have a bunch of client sessions using SFTP and SSHFS accessing the "MergerFS share".
Usually, No problem to 'umount' while using SFTP clients.
The problem comes from SSHFS connections from the clients.

My question is: If possible, How to see (from logs ? Wich ones ?) which client is connected and, is it possible to end their sessions without risking to kill my remote access to the NAS ?

I tried by stopping SSH service/daemond on the server, But (fortunately for my main remote access session) is does Not kill the already establshed SSH(FS) sessions.

Well, this question may be more a SSHFS challenge than a MergerFS one... But, 'umount' just fail with "umount: /path/to/merged/dir/: target is busy.", what seems directly related to MergerFS or am I completely wrong on the "stacking" between 'mount' + "MergerFS' + 'SSHFS' ?

If someone can point me toward the right direction, I will continue my search for an answer to my question.

Thanks a lot for reading me so far. :-)

Best regards,
HP_

[trapexit]

https://trapexit.github.io/mergerfs/error_handling_and_logging/#logging

This isn't a mergerfs thing.

No, there are no logs for that. That would be a huge amount of data that would be useless 99.9999% of the time. No filesystem I'm aware of does that kind of thing. Nor can it know the high level user of the filesystem. sshfs is abstracting that away. You need to look on the machine using sshfs. Use a tool like lsof to see what files are open in the mountpoint.

[HaroPo]

1. You just do lsof /path/to/mountpoint It will show all processes which have files open, the PID, etc.

Exactly what I have done each time.
'lsof' does work when trying it on /, But, I stopped it [CTRL]+[C] due to the excessive amount of data returned.

2. You absolutely can run numerous tune2fs commands on a mounted filesystem. `-m` included.

Good to know. I will still try on non-vital FS before to agree with you. 😉 😇

3. https://trapexit.github.io/mergerfs/config/options/#mount-options ; minfreespace... the minimal amount of space needed to consider a branch. The root filesystem is usually much smaller than storage mounts. So if minfreespace = 100G and the underlying filesystem you mount other shares to is less than that it simply isn't included in calculations. Just run through the logic of a policy with the mount removed. It behaves exactly the same with or with the mount. mergerfs does not care.

Sorry, it's confusing.
Do you mean that the main FS utilised to mount my SSD's partition would be considered as a storage area in case No SSD mounts exist (fstab issue, for example) ?

My setup is 4x 4TB SSD for dat storage + 256 GB eMMC for the NAS system itself.
"minFreeSpace" mount option for MergerFS is left to its default value of 4GB (I read somewhere in official documentation)

I thought that the main FS would Never been utilised at all for data storage by MergerFS.
So, is it correct to say, now, that the main FS disk space is involved into files storage if there is Not enough space on other drives/partitions or if they simply missing ?

This is something I did Not notice during those hours of reading. You should emphasis on this particular aspect in the man pages and other official documentation, if really the case, because it does Not appear at all when looking at how MergerFS is (nicely / efficiently) presented.

https://trapexit.github.io/mergerfs/runtime_interfaces/

I found this just before you replied. But, I recall reading somewhere that those special hidden files were deprecated because going to disappear in the future. Right ?

[trapexit]

Good to know. I will still try on non-vital FS before to agree with you. 😉 😇

If the filesystem is mounted and can't be changed it will just error. There is no risk.

Sorry, it's confusing.

mergerfs works exactly as it is described in the docs. It works on paths. Not mounts. You create a branch to /foo/bar and then you happen to mount something there... mergerfs does not care either way. It doesn't care when it starts, while it runs, when you shut it off. You can mount or unmount anything at any time (limited by active usage from the OS.)

I thought that the main FS would Never been utilised at all for data storage by MergerFS.

It won't... unless you point a branch to it... which if you unmount /mnt/foo and /mnt/foo is on the root filesystem then mergerfs uses /mnt/foo that happens to be on the root filesystem. Nothing more or less. It does not care there is a mount. If it did then it would be a problem to remove branches because it would actively need to hold the mount open. Meaning you wouldn't be able to unmount it without shutting mergerfs down or removing the branch.

You should emphasis on this particular aspect

It is explained in the docs I shared with you. The fact mergerfs does not work with mounts but paths. That filesystems can be added and removed at will. I can try to make it more clear but those facts mean what they say and that means they don't care about the mounts. Mounts are ephemeral things. They aren't proper objects. They are merely placed within the root filesystem tree.

I found this just before you replied. But, I recall reading somewhere that those special hidden files were deprecated because going to disappear in the future. Right ?

They will go away in mergerfs 3 whenever I get to writing and releasing it. But that is totally irrelevant to this conversation where you are asking about how to add or remove branches at runtime. That is the way.

[trapexit]

Please just use the docs on the main doc page. The man page is being removed and just generated from previous versions of the docs. The docs site is THE primary source of information and very comprehensive.

[HaroPo]

Thanks again for your prompt replies.

Please just use the docs on the main doc page. The man page is being removed and just generated from previous versions of the docs. The docs site is THE primary source of information and very comprehensive.

Noted.
But, Sincerely, I found the "man page" more helpful than the online documentation in the very beginning.
Both the man page and the online documentations are complementary despite some obvious redundancy.
Also, when you write scripts like I do, the man page comes in Very handy (and I thought, in the past, Never going to say this due to some Very poorly written man pages for other software) as it concentrate all the essential information to keep in mind or refresh the mind about.
Also, sometimes, there is No access to Internet for whatever reason, then the man page is the only help you get...

So, I vote for keeping the man page to be kept.
May be just add the Web link to online documentation with a message saying that users should consult it for latest up-to-date information and that they should refer to it if any issue arise. 😉

[trapexit]

The man page is literally the old online docs. Exactly. The online docs, a singular file, was converted with pandocs to man page. That is no longer possible with the mkdocs site. The man page has to be removed because I have no way currently to update it without doing a lot of duplicate effort which I just am not going to do. Any future manpage will be largely static and simple. Pointing to the online docs.