Ticket #2674 (closed enhancement: invalid)

Opened 11 years ago

Last modified 7 years ago

Reget doesn't read/write at block boundaries

Reported by: egmont Owned by:
Priority: minor Milestone:
Component: mc-core Version: 4.8.0
Keywords: Cc: mooffie@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:


Copy a larger file onto a smaller, and when asked for overwrite confirmation, choose "Reget". In the mean time, watch what mc is doing using strace.

What mc does: Seeks to the end of the target file, and to the same position in the source, and starts reading/writing full blocks (8192 bytes for me, I don't know if it depends on system settings).

This means that the underlying read() and write() requests work on both files at arbitrary unaligned offsets. Depending on the underlying file system's implementation, this might be slower than reading/writing from block boundaries. (Unfortunately I have no numbers about performance.)

What mc should ideally do: Start by copying a partial block first, so that all further read/write request are aligned to offsets that are multiple of the size of the read/write requests.


mc-4.8.0-reget-align.patch (1.3 KB) - added by egmont 11 years ago.
proof of concept

Change History

Changed 11 years ago by egmont

proof of concept

comment:1 Changed 11 years ago by egmont

Something along the lines of the attached patch maybe... Note that it might be nice to resync to aligned offset even in case of partial read or intermittent failure where you can continue (e.g. target filesystem full).

Note that I haven't tested the patch well yet... it should be stress-tested that it doesn't break normal copying or overwriting. I tested the Reget mode so far with source files that are and source files that are not multiple of the block size.

comment:2 Changed 11 years ago by egmont

(Oh, and the tricky bit by the way: in case of Append, you cannot align both the source and the target offset :-) I don't know which one is the better choice performance-wise. Currently the code seems to align the source.)

comment:3 in reply to: ↑ description Changed 11 years ago by ossi

Replying to egmont:

(Unfortunately I have no numbers about performance.)

so why are you even bothering?

comment:4 Changed 7 years ago by mooffie

  • Cc mooffie@… added

comment:5 follow-up: ↓ 6 Changed 7 years ago by egmont

I guess this one could be closed as invalid.

comment:6 in reply to: ↑ 5 Changed 7 years ago by andrew_b

  • Status changed from new to closed
  • Resolution set to invalid
  • Milestone Future Releases deleted

Ok. Closed.

Note: See TracTickets for help on using tickets.