RFC: SEEK_HOLE/SEEK_DATA common implementation

[mdf at FreeBSD.org]

On Thu, Mar 29, 2012 at 11:28 AM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Thu, Mar 29, 2012 at 06:56:31AM -0700, mdf at freebsd.org wrote:
>> On Thu, Mar 29, 2012 at 2:34 AM, Konstantin Belousov
>> <kostikbel at gmail.com> wrote:
>> > Filesystem probably should always fall back to calling vop_stdioctl()
>> > manually if it ever implements VOP_IOCTL, regardless of seek_hole/data.
>>
>> We can't if there's a use of VOP_BMAP() in one of the ioctls.  For
>> OneFS, a call to VOP_BMAP is fatal.  That operation doesn't work with
>> our system.
> But you had to already take some measure to disable the call to VOP_BMAP()
> for your filesystem, otherwise mmap() is fatal too (whatever the word
> fatal means) ?

Yes, OneFS does not support mmap().

>> We could implement SEEK_HOLE/SEEK_DATA semi-efficiently, but
>> implementing a custom filesystem becomes very complex once one has not
>> only to manage replacing all VOPs where the default doesn't work but
>> also has to know there's a bunch of ioctls in VOP_IOCTL that must be
>> handled as well.
>
> Does anything change if VOP_SEEKDATA() is added which default implementation
> using VOP_BMAP() ?

If it's a VOP it makes it easier to e.g. write a consistency checker
when creating a vnode, that the FS defines certain VOPs.  This could
be in conjunction with a mnt flag indicating support for various
features.

At the least, it's more expected, I'd think, for a filesystem to know
it has to handle all the VOPs listed in the table.  There's no global
list of all ioctls a filesystem is expected to handle.

Thanks,
matthew