Ticket #2674 (closed enhancement: invalid)
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: |
Description
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.
Attachments
Change History
Changed 13 years ago by egmont
- Attachment mc-4.8.0-reget-align.patch added
comment:1 Changed 13 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 13 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 13 years ago by ossi
Replying to egmont:
(Unfortunately I have no numbers about performance.)
so why are you even bothering?
proof of concept