Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10

From: David Borman <[email-masked]>
Date: Tue, 13 Jun 2000 10:09:46 -0500

> Date: Tue, 13 Jun 2000 09:22:54 -0500
> Reply-To: FTPEXT Working Group <[email-masked]>
> From: Robert Elz <[email-masked]>
> To: FTPEXT Working Group <[email-masked]>
> Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10
>
>     Date:        Tue, 13 Jun 2000 09:08:56 -0500
>     From:        David Borman <[email-masked]>
>     Message-ID:  <[email-masked]>
>
>   | Ok, I'll offer up another reasonable use of the SIZE command.
>
> For that, is the precise transfer size needed, or just a pretty good idea
> of roughly how big the file is going to be?

The exact size wasn't needed.  If I remember correctly, pre-allocation
didn't change the size of the file, that happened when you actually wrote
the data.  So if the pre-allocation size was too small, it'd just start
allocating more blocks when you got to the end.  If it was too big, then
you'd have some excess unused data blocks associated with the file.

> In fact, unless the storage encodings were identical to transfer encodings
> for all transfer types, all SIZE would be giving you is an approximation to
> the storage size in any case.

Well, for the interesting case (binary transfer), the storage encodings
and transfer encodings are identical.  If you have to do any massaging
of the data, you lose big time.  The Unicos FTP did a fair amount of work
to really grease the skids for the file transfer.  Besided doing file
pre-allocation, reads and writes to the file system were double buffered
and done asynchronously.  Files were pre-allocated whenever possible.
Socket buffers were bumped way up.  With continuous I/O operations to
both the network and the disk, FTP transfers pretty much went as fast
as the slower of the network and the disk would allow (as opposed to
the sum of the network and disk bottlenecks, as it is in the traditional
4.4 BSD implementation).

> I can understand making use of SIZE to do that, when the alternative was
> attempting to parse the output from LIST, but it seems to be overkill to
> me, assuming some other way of obtaining a good size estimate is available.

For binary transfers (again, the interesting case), the SIZE command
was trivial (just a stat() call), and provides exactly what is needed.
If you are doing an ASCII transfer, you've already shot yourself in the
foot with regards to performance.

			-David Borman, [email-masked]