But who does that? Are we actually hitting this problem?

The documentation follows up with "It is generally unwise to mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many cpus making intensive use of it."

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6c917630660164bb28d57f31b970b38591c0b8b1

commit 6c917630660164bb28d57f31b970b38591c0b8b1
Author: sriramsr <sriramsr@chromium.org>
Date: Wed Jul 20 02:57:37 2016

Return correct disk free/available size when FS is mounted with size = 0

When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
max_int64 instead.

BUG= 628710 

Review-Url: https://codereview.chromium.org/2152283003
Cr-Commit-Position: refs/heads/master@{#406473}

[modify] https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1/base/sys_info_posix.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5b052f0889962f08c818ea5bd9a525bbfabe9a2f

commit 5b052f0889962f08c818ea5bd9a525bbfabe9a2f
Author: phoglund <phoglund@chromium.org>
Date: Thu Jul 21 12:41:04 2016

Revert of Return correct disk free/available size when FS is mounted with size = 0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots: https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/builds/9516/steps/compile/logs/stdio:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c): undefined reference to `base::GetFileSystemType(base::FilePath const&, base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an Android bot though. host_forwarder is in the Chromium codebase. I would have understood it if it was WebRTC code since we have different macros (e.g. WEBRTC_LINUX) which would explain this breakage, but it appears to break host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only problem. Presumably you'll be able to repro if you generate with gyp and try to build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
>
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
>
> BUG= 628710 
>
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 628710 

Review-Url: https://codereview.chromium.org/2168843002
Cr-Commit-Position: refs/heads/master@{#406825}

[modify] https://crrev.com/5b052f0889962f08c818ea5bd9a525bbfabe9a2f/base/sys_info_posix.cc

CL reverted :( -> reopening.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9bbda42930813a781a034c378e1bcfbe90d503f8

commit 9bbda42930813a781a034c378e1bcfbe90d503f8
Author: sriramsr <sriramsr@chromium.org>
Date: Tue Aug 02 22:42:31 2016

Return correct disk free/available size when FS is mounted with size = 0

When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return max_int64 instead.

Also switch to using statfs() instead of statvfs() as f_type is not exposed via latter.

BUG= 628710 

Review-Url: https://codereview.chromium.org/2198283002
Cr-Commit-Position: refs/heads/master@{#409358}

[modify] https://crrev.com/9bbda42930813a781a034c378e1bcfbe90d503f8/base/sys_info_posix.cc