Date: Thu, 29 Mar 2012 06:56:31 -0700 From: mdf@FreeBSD.org To: Konstantin Belousov <kostikbel@gmail.com> Cc: fs@freebsd.org Subject: Re: RFC: SEEK_HOLE/SEEK_DATA common implementation Message-ID: <CAMBSHm8Qoj-Qhr_uXXYMe_M17ngU89ToK=ZLfKCs1TZCkYSM2w@mail.gmail.com> In-Reply-To: <20120329093427.GA2358@deviant.kiev.zoral.com.ua> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> <20120329091415.GA1316@reks> <20120329093427.GA2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 29, 2012 at 2:34 AM, Konstantin Belousov <kostikbel@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. 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. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm8Qoj-Qhr_uXXYMe_M17ngU89ToK=ZLfKCs1TZCkYSM2w>