BTW, the storage server in question, and the introducer through which Daira's client was seeing it, were both running 1.10.2 . I don't know what version daira's client was running, but it was something that supported magic-folders because that's the demo we were doing at the time. My 1.10.2 storage server, on its Welcome page, reported my storage server as having 9.35GB of space available, which matches what a local `df` says.

daira commented

2015-10-13 21:29:54 +00:00

Author

Owner

My client was running "1.10.2.post24 [2438.magic-folder-stable.3: 0b5039d2538ad8b139578427523188f765a0f135]".

Note that !18446744073.71 decimal-GB is 2^64^ bytes.

My client was running "1.10.2.post24 [2438.magic-folder-stable.3: 0b5039d2538ad8b139578427523188f765a0f135]". Note that !18446744073.71 decimal-GB is 2^64^ bytes.

tahoe-lafs changed title from ~~storage server running ~1.9.1 shows very large amount of space available to clients~~ to storage server running ~1.9.1 shows 2^64 bytes available to clients

2015-10-13 21:31:03 +00:00

warner commented

2015-10-13 21:52:19 +00:00

Author

Owner

Hm. I only see one place in the code where 2**64 makes an appearance, which is in the storage server, when fileutil_get_available_space() returns None. I've seen this return None on some virtual servers (maybe with network-based disks?), when the os.statvfs call fails: #2290 was for this happening on the Travis-CI build machines.

If that function returns None, then the server will indeed report that moon-sized available space.

The server in question was my own, and when I ran get_available_space() just now, it return about 10GB as expected. I did restart the server once or twice while we were setting up the demo (changing the webapi port's interface= so I could see it remotely). Maybe the statvfs failed the first time it came up, but succeeded the second time?

Hm. I only see one place in the code where `2**64` makes an appearance, which is in the storage server, when `fileutil_get_available_space()` returns None. I've seen this return None on some virtual servers (maybe with network-based disks?), when the `os.statvfs` call fails: #2290 was for this happening on the Travis-CI build machines. If that function returns None, then the server will indeed report that moon-sized available space. The server in question was my own, and when I ran `get_available_space()` just now, it return about 10GB as expected. I did restart the server once or twice while we were setting up the demo (changing the webapi port's interface= so I could see it remotely). Maybe the statvfs failed the first time it came up, but succeeded the second time?

tahoe-lafs changed title from ~~storage server running ~1.9.1 shows 2^64 bytes available to clients~~ to storage server running 1.10.2 shows 2^64 bytes available to clients

2015-10-13 21:52:19 +00:00

dawuud commented

2015-12-07 21:02:04 +00:00

Author

Owner

is this still an issue or can we close this ticket?

daira commented

2015-12-14 20:24:19 +00:00

Author

Owner

There has been no change that would have affected this ticket, so it should stay open.