johansen-osdev at sun.com wrote: > Can you explain in a bit more detail why we're doing this? I probably > don't understand the issue in sufficient detail. It seems like the > large file compilation environment, lfcompile(5), exists to solve this > exact problem. Isn't it the application's responsibility to properly > handle EOVERFLOW or choose an interface that can handle file offsets > that are greater than 2Gbytes? Is there something obvious here that I'm > missing? >
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. -Chris
