Possible feature request: sync_on_close mode for scp/sftp uploads

Jeremy Friesner jaf at meyersound.com
Thu Jul 1 09:06:20 EST 2010

Hi all,

First, my apologies if this is not the right forum for this... if there is a more appropriate place to make OpenSSH feature requests, or if this feature already exists, please let me know.

Some background:  My company makes an 'embedded' audio server box that runs Debian Linux, and one of the product's features is that users can upload files to the server via SSH, using their favorite SSH-compatible file-transfer program (e.g. command-line scp/sftp, CyberDuck, WinSCP, PSCP, etc).

That works fine, but one issue we have is that this box needs to be robust in the face of uncontrolled shut-downs:  in particular, since it is a headless "black box", our users expect to be able to just cut power to the box, without logging in and executing a "/sbin/shutdown -h now" first.  If cut power soon after completing an scp/sftp upload, however, they often find that last of their uploaded files end up truncated, because some of the uploaded data was cached in RAM and never got flushed to the disk before the power was cut.

I know one possible solution to this problem would be to mount the filesystems with the "sync" flag, so that all writes to the filesystem would be done synchronously.  However, I'm hesitant to do that because there are other processes running on the box (e.g. real-time audio recording) whose performance might be adversely by forcing every write() call to be synchronous.

Given that, my question is:  is there an option (or can an option be added) to force sshd to call fsync() on its uploaded-file's file-descriptors just before it calls close() on them?  That way when an scp/sftp upload completes, our users could be reasonably certain that all the uploaded data would make it onto the disk in the next second or two.  Perhaps a "sync_on_close" keyword in the /etc/sshd_config file would activate this behavior?  (I don't think it should be active by default, since that could unnecessarily affect performance in use cases where uncontrolled server shutdowns are not an issue)

Thanks for your time,

Jeremy Friesner
Meyer Sound Laboratories Inc.

More information about the openssh-unix-dev mailing list