Open ac55-sanger opened 4 years ago
@korydraughn this is now... handled?
somewhat ...
if an application (e.g. dd
) opens multiple streams to the same data object, then yes, the user will see improved performance.
however, a single stream between the client and NFSRODS will not result in parallel transfer between NFSRODS and the iRODS server.
NFSRODS never uses the traditional style of parallel transfer like iput
. Parallel transfer is purely driven by the client application speaking to NFSRODS.
Ah, I see.
the implementation does not provide a copy
function, so there is no obvious way to detect what operation was invoked by the user.
this makes it difficult to do parallel transfer in NFSRODS.
on the other hand, we may get faster transfers for free now that NFSRODS' write
operation supports parallel transfer over port 1247.
right - so let's list anything that is actionable here... and if that list is actually... nothing..., then let's close the issue.
sure thing.
because this issue is about the TODO item, we should adjust the title of this issue to indicate that parallel transfer here means pNFS (i.e. parallel transfer as defined by the NFS specification).
the nfs4j project contains copies of the RFCs it supports (or is planning to support).
those RFCs are located here: https://github.com/dCache/nfs4j/tree/nfs4j-0.19.0/docs
the documents referenced here are for the 0.19.0 version of nfs4j (i.e. the version of nfs4j used by NFSRODS).
NFSRODS is not performant while doing I/O operations on 1.3 GB file using basic cp command on the mounted directory.
server.json:
Here are the stats:
icommands: iput: 0m6.549s iget: 0m4.777s
Unix cp command: Write: 4m53.061s Read: 5m4.880s
I see that the implementation of support for Parallel File Transfers is in your TODO list. Just logging an issue to track it.