> This could be a bad thing if the application thinks that all of the > information in the statvfs structure is valid, when only some of it is > valid. Why not set the invalid fields in the statvfs structure to > something distinctive like -EOVERFLOW instead of the proposed change of > setting such fields to the "smallest power of 2 that won't cause > EOVERFLOW?" It's better to return something that's obviously garbage > than it is to return something that looks like it's valid when it's not?
I don't think that Chris is proposing that we return invalid data to the application. Rather, I think he's talking about increasing the size that we report blocks to be in the statvfs structure. statvfs(2) explains this in a little more detail. Basically, f_frsize is a scaling factor for f_blocks, f_bfree, and f_bavail. IIUC, Chris is proposing adjusting the scaling factor to avoid integer overflow. Thus, if f_frsize is 512b and f_blocks is UINT32_MAX, perhaps we could set f_frsize to 1024b and have f_blocks be 2^31 instead. This means that there's a potential to overreport the amount of space used. However, we already have and use a scaling factor, so we've been doing this since day one. This seems to be a philosophical question, not one of correctness. Chris, correct me if I got any of that wrong. -j
