Ticket #4315 (new enhancement)

Opened 7 months ago

Last modified 7 months ago

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:



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 7 months 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 7 months ago by zaytsev

It could be related to block size:


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.

Note: See TracTickets for help on using tickets.