Forums
New posts
Search forums
What's new
New posts
Latest activity
Members
Current visitors
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Audio and Video Talk
Computers & Networking
mergerfs - pooling of disks in linux (JBOD)
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Help Support AVForums:
This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Message
<blockquote data-quote="trapexit" data-source="post: 672120" data-attributes="member: 18399"><p>It is atypical but you still have to check your system for end to end performance. Even with 6GbE you may be limited by how you transfer. Are you going to use NFS or CIFS? Speed of your devices? CPU speed. Etc.</p><p></p><p>Caching complicates things quite a bit and given mergerfs isn't intended to be competing with those techs which tend to offer it (nor would probably gain much from supporting it directly given FUSE itself would probably be a bottleneck) I don't see the need. Most people who talk about caches mean "I think I'll get faster speeds if I write to an SSD rather than my spinning disks" which is almost never true end to end unless you have a particularly slow drive. And for those cases there are probably easier/simpler ways of handling it. If you're going to have a serious storage setup you'll be using LVM and it's caching or some RAID5/6 setup which probably wouldn't need it. Mergerfs is not intended nor would suffice for a high throughput, big storage solution.</p><p></p><p>I'm not opposed to creating something that augments mergerfs' abilities for certain caching usecases but as I mentioned I don't know that FUSE is fast enough for it to matter *that* much. Would need to see what kind of performance mergerfs has writing to a RAM fs or SSD and understand usage patterns. If it's "want to write fast once and read can be from slower drives" that can be done somewhat easily. Full caching however is a different beast all together.</p></blockquote><p></p>
[QUOTE="trapexit, post: 672120, member: 18399"] It is atypical but you still have to check your system for end to end performance. Even with 6GbE you may be limited by how you transfer. Are you going to use NFS or CIFS? Speed of your devices? CPU speed. Etc. Caching complicates things quite a bit and given mergerfs isn't intended to be competing with those techs which tend to offer it (nor would probably gain much from supporting it directly given FUSE itself would probably be a bottleneck) I don't see the need. Most people who talk about caches mean "I think I'll get faster speeds if I write to an SSD rather than my spinning disks" which is almost never true end to end unless you have a particularly slow drive. And for those cases there are probably easier/simpler ways of handling it. If you're going to have a serious storage setup you'll be using LVM and it's caching or some RAID5/6 setup which probably wouldn't need it. Mergerfs is not intended nor would suffice for a high throughput, big storage solution. I'm not opposed to creating something that augments mergerfs' abilities for certain caching usecases but as I mentioned I don't know that FUSE is fast enough for it to matter *that* much. Would need to see what kind of performance mergerfs has writing to a RAM fs or SSD and understand usage patterns. If it's "want to write fast once and read can be from slower drives" that can be done somewhat easily. Full caching however is a different beast all together. [/QUOTE]
Insert quotes…
Verification
Post reply
Audio and Video Talk
Computers & Networking
mergerfs - pooling of disks in linux (JBOD)
Top
