openssh unix dev - Feb 2006 - scp and SGI DMF

Hello,

For some time now, our users have been encountering a problem when using scp
to overwrite files on our mass-storage system, which uses SGI's DMF
product. I don't have any data as to whether or not any other HSMs would be
similarly affected.

The scenario is that a user is overwriting a file (via scp) that has previously
been migrated to tape. The scp opens the file for writing, but does not
truncate the file. This causes DMF (the HSM) to recall the file from tape and
the scp hangs until it is successfully recalled.

Unfortunately, these recalls can take several hours depending on how active the
tape drives are.

So, I'm wondering if there would be any interest in either adding (yet
another)
command-line option to add O_TRUNC to the open() flags when writing a file or
perhaps to change the default behaviour. (I'm assuming the latter is
unlikely.)

I should note that sftp doesn't seem to have the same problem. However, the
lack
of a recursive copy makes it problematic for many of our users.

Thanks

--
Iain Morgan

On Tue, Feb 28, 2006 at 03:58:27PM -0800, Iain Morgan
wrote:
> This causes DMF (the HSM) to recall the file from tape and the scp
> hangs until it is successfully recalled.
Oh.

> So, I'm wondering if there would be any interest in either adding
> (yet another) command-line option to add O_TRUNC to the open()
> flags when writing a file
I doubt this will ever happen. scp is only maintained for backwards
compatibility with rcp.

> or perhaps to change the default behaviour. (I'm assuming the
> latter is unlikely.)
Can you test what rcp does? The general intention for scp is that it
should behave the same way rcp does, if rcp truncates then scp may
quite possibly change.

> I should note that sftp doesn't seem to have the same problem.
> However, the lack of a recursive copy makes it problematic for many
> of our users.
Teaching sftp how to do recursive copies is probably the best
solution in any case since sftp is actually developed rather than
just maintained.


//Peter