Downloads fail with category.create=eplfs

[8ullyMaguire]

I have multiple drives that are almost full, and one that is free. I want to download files to the drives with the least free space, but still enough space for the file. Using moveonenospc=true would probably require trying many different drives before succeeding, and moveonenospc=mfs is not what I want to achieve. The right approach would be to create the file in MFS and, upon success, move it again to LFS. By then, knowing the size of the whole file, it shouldn't fail.

The most straightforward solution would be to use a separate directory or drive for downloads that is not part of the mergerfs pool. After downloads complete, I can move the files to the mergerfs pool. This approach ensures that downloads won't fail due to space issues. Since I have enabled ignorepponrename, I can't just download to a folder in the pool and then move them within it for it to be moved to the appropriate drive.

I think I'll use moveonenospc=mfs for now since I don't want to complicate myself and I don't know how to achieve what I want. I don't want to increase minfreespace.

Is there some way to fill all drives completely before using the empty one and have downloads work properly?

Here is the /etc/fstab content:

/mnt/*/personal:/run/media/user/*/personal  /personal  fuse.mergerfs  allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=eplfs,ignorepponrename=true,func.mkdir=epall,minfreespace=0G,x-gvfs-show  0  0
/mnt/*/public:/run/media/user/*/public  /public  fuse.mergerfs  allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=eplfs,ignorepponrename=true,func.mkdir=epall,minfreespace=0G,x-gvfs-show  0  0
/mnt/*/personal:/mnt/*/public:/run/media/user/*/personal:/run/media/user/*/public  /media  fuse.mergerfs  allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=eplfs,ignorepponrename=true,func.mkdir=epall,minfreespace=0G,x-gvfs-show  0  0

[trapexit]

First, it's not "failing" in the sense that mergerfs is doing something wrong. If you have it set to eplfs it's doing eplfs and the failure to find a branch is because that's what it is designed to do.

Second, it would help if you explained why you want that behavior. If you just want to fill drives why not use ff? "but still enough space for the file. " That's not something mergerfs can know at runtime. You can only do that kind of binpacking when nothing is changing and you know the sizes of everything.

[8ullyMaguire]

Second, it would help if you explained why you want that behavior. If you just want to fill drives why not use ff?

I want to fill all drives before filling the new one. I don't have any other reason beyond using all space in the drives. If I choose 'first found,' I'm going to have the same issue; it will fail unless it has enough space for the whole download, which isn't known until it's complete. Then it will write to 'most free space' if I have moveonenospc=true. So it wouldn't be any better than what using eplfs does.

Is there some way to fill all drives completely before using the empty one and have downloads work properly?

[trapexit]

Most filesystems don't like being filled all the way so that is not recommended.

"which isn't known until it's complete" It's never known from the perspective of the filesystem APIs. There is no such thing as "download file" vs "copy file." There is "open/create", "write", "close". Where that "write" comes from could be anything. Could be an app streaming data from the network or a file copy. I can't, at create time, know what is going on or what the size of incoming data is. And files can have many writers so the size is just some snapshot in time.

The only way to accomplish what you seem to be asking for would be to try to keep track of all accesses to the file and on close move it to another branch. But 1) keeping track of all accesses isn't really possible and 2) how would I know the file needs to be moved on closed? Because it happened to be created on open vs not?

At best on close it could start copying it to another branch and at the end of file check if the source file changed size or mtime and try again or give up.

[8ullyMaguire]

Thanks.

I think something about this should be mentioned in the README because I didn't have any idea.

Knowing this, I think I'll use a different download folder and then move the files to their appropriate drive using first found.

allow_other,
use_ino,
cache.files=partial,
dropcacheonclose=true,
category.create=epmfs,
func.mkdir=epall,
func.rename=epff,
ignorepponrename=false, (default)
moveonenospc=epmfs,
lazy-umount-mountpoint=true,
minfreespace=4G, (default)
x-gvfs-show

[trapexit]

What should be mentioned?

As I mentioned there is no such thing as "move file". What you propose is the same as before more or less.

[8ullyMaguire]

What should be mentioned?

Mergerfs is unable to determine the size of a file while it's being written; this knowledge is only available when the file is being moved. If func.create=lfs is chosen and you attempt to download a file, it will likely fail to download. I've been experiencing this issue for a while, but I didn't understand why until now. I had assumed that mergerfs would automatically choose a drive with sufficient space available for writing files, but that's not possible if it can't determine the size of the files being written.

What you propose is the same as before more or less.

Wait, so even when renaming files and sending them to lfs it will still fail because it doesn't know the size of the files?

[trapexit]

This isn't a limitation of mergerfs. It is universal to filesystems. I can add it in the docs but everything I've explained is how all filesystems work. There is no API to tell the filesystem how large the file is at create time. The command is literally "open(PATH,FLAGS)" or "creat(PATH,FLAGS)". That's all the info available about the open/create. And at that point in time mergerfs has to open the file somewhere. There is also no such thing as "move". There is "rename" and there is "open file A, open file B, read A, write B, repeat till end of file A, close A, close B". And the latter is not "open(A,B)". It's two entirely separate opens with at best the same process as any indication that they are related.

I'll add some details to the docs but at the end of the day you have to understand Unix filesystems to understand what mergerfs can and can't do.