RFC: should a va_bytes option be added to vn_getsize_locked()?

[Rick Macklem]

Hi,

I would like to compare va_size to va_bytes in vn_generic_copy_file_range(),
as a heuristic to check for a sparse file (only works for non-compressed
file systems).

The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked()
in vn_generic_copy_file_range().

To get va_bytes I can either modify the code to again use VOP_GETATTR()
or I could add an additional return argument to vn_getsize_locked().
Since vn_getsize_locked() is descibed as a first step towards not using
VOP_GETATTR() it sounds like adding an agument to vn_getsize_locked()
is not the preferred alternative, but I thought I'd ask.

Thanks for any comments, rick


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Konstantin Belousov]

Post by Rick Macklem
Hi,
I would like to compare va_size to va_bytes in vn_generic_copy_file_range(),
as a heuristic to check for a sparse file (only works for non-compressed
file systems).
The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked()
in vn_generic_copy_file_range().
To get va_bytes I can either modify the code to again use VOP_GETATTR()
or I could add an additional return argument to vn_getsize_locked().
Since vn_getsize_locked() is descibed as a first step towards not using
VOP_GETATTR() it sounds like adding an agument to vn_getsize_locked()
is not the preferred alternative, but I thought I'd ask.

For me it sounds as very specific usage. You might be better served by
directly using VOP_GETATTR() then IMO.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de