Chris Kirby wrote: > It's not a large file issue, it's a large *filesystem* issue > that revolves around f_frsize unit reporting via the cstatvfs32 > interface. f_blocks, f_bfree, and f_bavail are all reported in > units of f_frsize. > > For ZFS, we report f_frsize as 512 regardless of the size of > the fs. This means we can only express vfs size up to > UINT32_MAX * 512 bytes. That's not a terribly large fs > by today's standards. Anything larger will result in EOVERFLOW > from statvfs. > > You're entirely correct that it's the application's responsibility > to deal with EOVERFLOW, perhaps by using statvfs64. But if we can > return valid information instead of an error, that seems like a > good thing.
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? _______________________________________________ ufs-discuss mailing list [email protected]
