User Feedback Request: mergerfs
Added 2018-12-05 21:19:13 +0000 UTCAre there any features people are looking for? Tutorials / howtos they'd like to see?
Some things I'm considering:
* statfs caching: statfs calls are on the expensive side and done regularly but on average the data doesn't change drastically between each call. A cache may help improve performance with certain usage patterns.
* stat caching: less likely to be as useful due to the number of possible values and typical use patterns.
* writeback caching: found in libfuse3. may help improve performance of small writes. Could try doing this myself in mergerfs as well.
* rewrite using low level libfuse API: not really a feature but *might* improve performance. A lot of work without known benefits.
* enhance mergerfs-tools dup and dedup to handle different usecases
* a new howto and tool to help put a SSD cache in front of a pool of slower drives
* change xattr runtime config to a directory/file setup: turning off xattrs can improve performance but kills the xattr runtime config API. Moving to a regular dir/file model would let you keep runtime config and disable xattr.
Comments
Is this still of interest? I've another request for it but I'm still unsure of it's use. Is it just to limit entropy of files?
trapexit
2019-06-06 12:22:50 +0000 UTCIt feels like a contradiction to me. minfreespace is to act like ext{2,3,4} space reservation. path preservation is for partitioning a pool so you could kindof act like it is separate pools (which thereby requires manual intervention). If you don't actually care to keep the pool segregated why enable path preservation? The point is to explicitly error when you run out of space so you know. If it silently ignores the behaviour when you caret he most to know it happened what is the point of the feature? You might as well just minfreespace=0 and policy=mfs. (which is what most people expect and want).
trapexit
2018-12-16 21:47:35 +0000 UTCI'd like to see path preserving policy with fallback option, like you described in issue #540, if it is not too much work. If no selected drive has enough space, try the next strategy (E.g. "epmfs,mfs").
2018-12-16 20:49:27 +0000 UTCThe idea would be to have a tool to simplify setting up of LVM caching in a JBOD environment. It's all possible today but requires manual setup.
trapexit
2018-12-07 20:06:22 +0000 UTCmergerfs already has more features than I know how to use, but that SSD cache tool sounds enticing.
2018-12-07 17:27:14 +0000 UTCre performance tests... yeah... been meaning to throw together a few. need to think of the best things to test.
trapexit
2018-12-06 02:58:46 +0000 UTCIt's difficult to know how efficient the high level API is in relation to the low level. The threading model is not good and on the surface there looks like a possibility of contention on the data structure holding the filesystem hierarchy. The main interest is control. The high level API hides away things which make the handling of a few situations more difficult. I'll probably just try to modify the API first.
trapexit
2018-12-06 02:57:07 +0000 UTCTo be honest, I don't need any new features now, but in about 4 month SSD cache would be cool. On low-level libfuse API, I would like to know your thoughts on <a href="https://sourceforge.net/p/fuse/mailman/message/31925484/" rel="nofollow noopener" target="_blank">https://sourceforge.net/p/fuse/mailman/message/31925484/</a> On all caching, it would be great to make quick'n'dirty performance test for every option before choosing one.
Mikhail Gorodetskiy
2018-12-06 00:04:06 +0000 UTC
