Adam Nielsen wrote... > I'm wondering whether it is feasible to have an option that will make > rsync spawn a separate thread to close files it has created, to avoid > the main process blocking while the destination files are flushed during > the close operation?
While your scenario resembles a problem I've been experiencing for years, I'm not sure whether such a change would help. > The reason I ask is that it is currently very slow to use rsync on a > fast locally-mounted network filesystem, as you see the following > behaviour: If I understand correctly, you transfer from a local file system to a network (CIFS) one. Does this happen in a local-local scenario as well? And, is this related to to the size of the files? My woes were copying many rather small (100k) files unto a USB flash drive. Once the buffers are filled up, write rate drops to somewhat one percent of the raw value (like 200 kbyte/sec on a USB 2.0 drive). My workaround was to switch the file system from ext4 without journal to f2fs, assuming ext4 puts inode commits into an isolated transaction (no-barrier didn't help). Might be a different story but it sounded somewhat familiar. Christoph -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html