-
|
I want to fill my 5 disks one by one, using mergerfs. That is, applications should write data in one disk first, and should always write into such disk, until it is full (or have low space, 20G remaining, e.g.). When the disk is full, applications should write to another disk, one by one, by the same mean. My situation is I want to merge my 5 disks into one, but keep them sleeping for the most time. I do not want to wake up all my disks time by time, due to noise. And I really do not care about speed and reliability, because I have an SSD for fast read/write and I backup my important data to S3 daily. My question is: can mergerfs meets my demand? If it can, how? I tried using epmfs policy, and moveonenospc=true. But I cannot write data when the available space of that disk is less than minfreespace. Should I try something like mspmfs? Or are there any other options or flags which can just meet my need? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
Just use |
Beta Was this translation helpful? Give feedback.
-
|
That said... https://github.com/trapexit/mergerfs/wiki/Limit-Drive-Spinup You can't get away from spinup that way. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! Such great documentation deserves a reference in the Readme.md, as far as I think. So I can use Would the metadata of underlying filesystems be cached can avoid the spinup of disks when performing some structure operation, such as listing or changing the directory? And I do not need a huge cache, which caches the whole file to read, and I can read the file with only one disk spined up. Am I right? |
Beta Was this translation helpful? Give feedback.
-
|
The kernel already caches things and you have control over what parts of mergerfs the kernel can cache. mergerfs does not do its own explicit caching of things. As I mention in the docs it is non-trivial to keep things aligned when mergerfs doesn't own the underlying data. Yes, you can use block caching to help but LRU caches are LRU caches. There is no guarantee any particular data is going to be there. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Why? Please just create a new discussion entry for new questions. |
Beta Was this translation helpful? Give feedback.
The kernel already caches things and you have control over what parts of mergerfs the kernel can cache. mergerfs does not do its own explicit caching of things. As I mention in the docs it is non-trivial to keep things aligned when mergerfs doesn't own the underlying data.
Yes, you can use block caching to help but LRU caches are LRU caches. There is no guarantee any particular data is going to be there.