3 ms·
I'm surprised that the copying bottleneck seems to have been entirely at the target rather than the source. Is that because there were multiple copies of the s
by gnufx 11y ago
I'm surprised that the copying bottleneck seems to have been entirely at the target rather than the source. Is that because there were multiple copies of the source?
I've had to employ the horrible hack of iscsi from compute nodes, raided and re-exported, but it's not what I'd have tried to use first. The article doesn't mention the possibility of just spinning up a parallel filesystem on compute node local disks (assuming they have disks); I wonder if that was ruled out. I don't have a good feeling for the numbers, but I'd have tried OrangeFS on a good number of nodes initially.
By the way, it's been pointed out that RAM disk is relatively slow, if in the context of data rates rather than metadata <http://mvapich.cse.ohio-state.edu/static/media/publications/slide/rajachan-hpdc13.pdf> http://mvapich.cse.ohio-state.edu/static/media/publications/....
- ople 11y agoThe reading of the metadata required quite a lot of random acces. We were fairly sure that if a high-end array and controller with fast disks is struggling with it, then a traditional clustered solution with slower node local disks would not fare much better. Thus we tried to find the solution which yields the highest possible IOPS.
- gnufx 11y agoI misunderstood the bottleneck, not having had to do that. (Distributed metadata for the parallel filesystem could actually be tuned to be memory resident.)