Ticket #4315 (new enhancement)
slow copy performance when using LTFS as a destination
| Reported by: | aletib | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Future Releases |
| Component: | mc-core | Version: | master |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Branch state: | no branch | Votes for changeset: |
Description
Hi!
I'm using MC v 4.8.24 on ubuntu 20.04
Built with GLib 2.63.3
I recently started using LTFS (a standard platform-independent feature that allows to mount LTO tapes as a file system) and noticed that when I'm copying from a local file system to a folder mapped to an LTFS-mounted tape, performance is very slow (about 20MB/s).
cp or any other copy system (of course copy same files from same source to same destination) have expected thorughput (+130MB/s).
The problem is not present if I use MC to copy from the folder mapped to the LTFS tape back to local drives so I assume this must be something related to the write process (or write speed measurement) that MC uses.
It would be cool to keep using MC for moving files to tapes especially for its selection interface.
Let me know if you'd like me to collect further info, thanks!
Change History
comment:1 Changed 3 years ago by aletib
- Summary changed from slow copy performance when using as a destination to slow copy performance when using LTFS as a destination
comment:2 Changed 3 years ago by zaytsev
It could be related to block size:
https://github.com/coreutils/coreutils/blob/master/src/ioblksize.h#L23-L57
After fixing #2193, it depends on the target system, but is at least 128K or larger since 4.8.17. There was another problem with rotating dash generating too much output - #3859 - but this should have been fixed in 4.8.24 already.
You are saying, that if you copy FROM tape with mc, everything is fine, the problem is only in the direction TO tape. So I would assume that dash should be no problem, but your tape FS advertises block size lower than 128K, whereas your local FS advertises a higher block size.
You can check what ST_BLKSIZE is and test the performance of higher sizes by building mc from source and hardcoding a block size of 1M for example, it it's lower than 128K. Only, it's weird that cp that allegedly uses the same algorithm performs better... not sure what we can do about it though.
