openssh unix dev - Jun 2010 - Possible feature request: sync_on_close mode for scp/sftp uploads

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.

On Wed, Jun 30, 2010 at 18:06:20 -0500, Jeremy Friesner
wrote:
> 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.
> 
No such option currently exists. Also, it's scp and sftp-server that
would need to call fsync(), neither of which read the sshd_config.

-- 
Iain Morgan

Try something with "Subsystem" in sshd_config. Where you redefine sftp
to be something like "sftp-server && sync".

Might need to embed that in a python/bash/perl script so your
subsystem isn't a bash expression... ;)

On Wed, Jun 30, 2010 at 4:06 PM, Jeremy Friesner <jaf at meyersound.com>
wrote:
> 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.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Le 01/07/10 06:26, Carson Gaspar a ?crit :
> You can also write a simple LD_PRELOAD module to overload close() to
> also fsync(), and use it with whichever services you desire.
Or even better, edit the sources of scp.c and sftpd.c and add the fsync 
thing. It takes 10 minutes at most.

Aris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5610 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100701/efbe98b8/attachment.bin>

Bryan Whitehead wrote:
> Try something with "Subsystem" in sshd_config. Where you redefine
sftp
> to be something like "sftp-server && sync".
Sync will (in theory) cause the entire contents of the filecache to be flushed 
to disc right?

rick jones
occasionally still goes sync; sync; sync; reboot....

Recalls, stage, have put some pressure on ranch causing about a 3 to 4 hour
delay.   I made some changes that will help.

Were looking into some changes that will help the recalls.   

Bill Jones

-----Original Message-----
From: openssh-unix-dev-bounces+jones=tacc.utexas.edu at mindrot.org
[mailto:openssh-unix-dev-bounces+jones=tacc.utexas.edu at mindrot.org] On Behalf
Of Rick Jones
Sent: Thursday, July 01, 2010 12:00 PM
To: Bryan Whitehead
Cc: Jeremy Friesner; openssh-unix-dev at mindrot.org
Subject: Re: Possible feature request: sync_on_close mode for scp/sftp uploads

Bryan Whitehead wrote:
> Try something with "Subsystem" in sshd_config. Where you redefine
sftp
> to be something like "sftp-server && sync".
Sync will (in theory) cause the entire contents of the filecache to be flushed 
to disc right?

rick jones
occasionally still goes sync; sync; sync; reboot....
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev