[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1285: SFTP: put an approximation of grid capacity and available space in the 'df' output

[Tahoe-LAFS]

#1285: SFTP: put an approximation of grid capacity and available space in the 'df'
output
-------------------------------------+-------------------------------------
     Reporter:  davidsarah           |      Owner:
         Type:  defect               |     Status:  new
     Priority:  normal               |  Milestone:  undecided
    Component:  code-frontend-ftp-   |    Version:  1.8.1
  sftp                               |   Keywords:  usability statistics
   Resolution:                       |  sftp ostrom
Launchpad Bug:                       |
-------------------------------------+-------------------------------------
Changes (by warner):

 * component:  code-frontend => code-frontend-ftp-sftp


Old description:

> Ticket #648 is about collecting server capacities and putting them on the
> welcome page. This might also allow a better approximation of available
> space than what SFTP currently outputs for 'df'.
>
> Because the SFTP protocol did not originally have a way of implementing
> 'df', clients use either an extension (implemented at
> [source:src/allmydata/frontends/sftpd.py at 4545#L1757 sftpd.py
> SftpUserHandler.extendedRequest]) or try to log in to the server and
> issue a 'df' command (implemented in
> [source:src/allmydata/frontends/sftpd.py at 4545#L1879 sftpd.py
> ShellSession.execCommand]). sshfs does the latter, and will not mount the
> filesystem if it cannot do so. Currently we always report 314159265 KiB
> free, and double that capacity, to keep sshfs happy.
>
> However, even given the space available on each server, it is not
> entirely obvious what to report as the total space available on the
> filesystem. Brian wrote in ticket #648:
> > Wait, what? What's the relationship between server-space available and
> the number that SFTP reports as available to any given client? Not
> trivial, I think.
>
> > If we do this, let's make it clear that we're providing only a very
> rough approximation of the client-side space. Adding together all of the
> raw server space and dividing by the expansion factor is pretty rough,
> especially with the servers-of-happiness change (e.g. one server has 14TB
> free, but you can't upload anything because everyone else is full: SFTP
> should announce 0).
>
> > Also let's make room for Accounting APIs to generate this data (since
> really it's a function of accounting: how much space an individual "user"
> is allowed to consume, which may be far less than the sum of all server
> capacities). At least let's be thinking in that direction when we name
> the functions.

New description:

 Ticket #648 is about collecting server capacities and putting them on the
 welcome page. This might also allow a better approximation of available
 space than what SFTP currently outputs for 'df'.

 Because the SFTP protocol did not originally have a way of implementing
 'df', clients use either an extension (implemented at
 [source:src/allmydata/frontends/sftpd.py at 4545#L1757 sftpd.py
 SftpUserHandler.extendedRequest]) or try to log in to the server and issue
 a 'df' command (implemented in
 [source:src/allmydata/frontends/sftpd.py at 4545#L1879 sftpd.py
 ShellSession.execCommand]). sshfs does the latter, and will not mount the
 filesystem if it cannot do so. Currently we always report 314159265 KiB
 free, and double that capacity, to keep sshfs happy.

 However, even given the space available on each server, it is not entirely
 obvious what to report as the total space available on the filesystem.
 Brian wrote in ticket #648:
 > Wait, what? What's the relationship between server-space available and
 the number that SFTP reports as available to any given client? Not
 trivial, I think.

 > If we do this, let's make it clear that we're providing only a very
 rough approximation of the client-side space. Adding together all of the
 raw server space and dividing by the expansion factor is pretty rough,
 especially with the servers-of-happiness change (e.g. one server has 14TB
 free, but you can't upload anything because everyone else is full: SFTP
 should announce 0).

 > Also let's make room for Accounting APIs to generate this data (since
 really it's a function of accounting: how much space an individual "user"
 is allowed to consume, which may be far less than the sum of all server
 capacities). At least let's be thinking in that direction when we name the
 functions.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1285#comment:7>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage