RFC: SEEK_HOLE/SEEK_DATA common implementation

Konstantin Belousov kostikbel at gmail.com
Thu Mar 29 18:28:53 UTC 2012


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) ?

> 
> 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() ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20120329/51a65e49/attachment.pgp


More information about the freebsd-fs mailing list