|
|
DescriptionReturn 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
Committed: https://crrev.com/9bbda42930813a781a034c378e1bcfbe90d503f8
Cr-Commit-Position: refs/heads/master@{#409358}
Patch Set 1 #
Total comments: 2
Patch Set 2 : Switch to statfs() instead of statvfs() as f_type is not exposed via latter. #
Total comments: 3
Patch Set 3 : Fix include for Mac OS X #Patch Set 4 : Call statfs only in Linux. #
Total comments: 1
Patch Set 5 : Update based on CR comment and fix try bot failure. #Messages
Total messages: 33 (21 generated)
sriramsr@chromium.org changed reviewers: + thestig@chromium.org
https://codereview.chromium.org/2198283002/diff/1/base/sys_info_posix.cc File base/sys_info_posix.cc (right): https://codereview.chromium.org/2198283002/diff/1/base/sys_info_posix.cc#newc... base/sys_info_posix.cc:98: stats.f_blocks == 0 && IsStatsZeroIfUnlimited(stats.f_fsid); Are you sure f_fsid is the right field to check? Locally I ran this program: #include <stdio.h> #include <sys/statvfs.h> int main() { struct statvfs stats; statvfs("/run/shm/foo", &stats); printf("%lu\n", stats.f_fsid); return 0; } and it returned 0, for a file foo that exists on /run/shm, which is tmpfs.
The CQ bit was checked by sriramsr@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== 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 ========== to ========== 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 ==========
https://codereview.chromium.org/2198283002/diff/1/base/sys_info_posix.cc File base/sys_info_posix.cc (right): https://codereview.chromium.org/2198283002/diff/1/base/sys_info_posix.cc#newc... base/sys_info_posix.cc:98: stats.f_blocks == 0 && IsStatsZeroIfUnlimited(stats.f_fsid); On 2016/08/01 21:30:55, Lei Zhang wrote: > Are you sure f_fsid is the right field to check? Locally I ran this program: > > #include <stdio.h> > #include <sys/statvfs.h> > > int main() { > struct statvfs stats; > statvfs("/run/shm/foo", &stats); > printf("%lu\n", stats.f_fsid); > return 0; > } > > and it returned 0, for a file foo that exists on /run/shm, which is tmpfs. You are right - I misunderstood the man page and f_fsid is not the same as f_type and f_type is not exposed via statvfs() call. Switched to statfs() as all values needed here is available.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
You've got red bots. https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc File base/sys_info_posix.cc (left): https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc#... base/sys_info_posix.cc:24: #if defined(OS_ANDROID) Ok, hope this works. https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc File base/sys_info_posix.cc (right): https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc#... base/sys_info_posix.cc:25: #include <linux/magic.h> Now that you have removed the #if, move these up to the line 7 block, and keep them in alphabetical order.
The CQ bit was checked by sriramsr@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: ios-device on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...) ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
Now I suspect the reason statvfs was used is because of Mac. I think it's cleaner to keep statvfs(), and do an extra statfs() call in the Linux-only code. I don't think we ask for the free disk space that often, so the slight inefficiency is ok.
The CQ bit was checked by sriramsr@chromium.org to run a CQ dry run
On 2016/08/02 19:15:19, Lei Zhang wrote: > Now I suspect the reason statvfs was used is because of Mac. I think it's > cleaner to keep statvfs(), and do an extra statfs() call in the Linux-only code. > I don't think we ask for the free disk space that often, so the slight > inefficiency is ok. Agreed and done.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
lgtm https://codereview.chromium.org/2198283002/diff/50001/base/sys_info_posix.cc File base/sys_info_posix.cc (right): https://codereview.chromium.org/2198283002/diff/50001/base/sys_info_posix.cc#... base/sys_info_posix.cc:33: #include <linux/magic.h> alphabetical order
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
The CQ bit was checked by sriramsr@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc File base/sys_info_posix.cc (left): https://codereview.chromium.org/2198283002/diff/20001/base/sys_info_posix.cc#... base/sys_info_posix.cc:24: #if defined(OS_ANDROID) On 2016/08/02 00:11:48, Lei Zhang wrote: > Ok, hope this works. Acknowledged.
++lgtm
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by sriramsr@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== 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 ========== to ========== 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 ==========
Message was sent while issue was closed.
Committed patchset #5 (id:70001)
Message was sent while issue was closed.
Description was changed from ========== 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 ========== to ========== 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 Committed: https://crrev.com/9bbda42930813a781a034c378e1bcfbe90d503f8 Cr-Commit-Position: refs/heads/master@{#409358} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/9bbda42930813a781a034c378e1bcfbe90d503f8 Cr-Commit-Position: refs/heads/master@{#409358} |