From owner-freebsd-fs@FreeBSD.ORG Thu Mar 29 18:34:35 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 760AB106564A for ; Thu, 29 Mar 2012 18:34:35 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 451918FC15 for ; Thu, 29 Mar 2012 18:34:35 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so554440pbc.13 for ; Thu, 29 Mar 2012 11:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zNR6fuRgu4D/BKOV+2NR7aUOWPQAjV8Xk7IKFEdR8J8=; b=FOZDIqO6f47F01pR9JFrzF+BA45mxyAOkyOfXOd690Cg8qUZhq0scgipVcVYPTHlN1 KNTD4Cd/Ce9w61mQSFQDrD7qcX3cCUUyl/5x9qaX+te0CIIUTgi+lpELKta4LqYTgbat TnnkCBCYZ2BWjpi+Yl2wi5hm9kxltoVd5Yvm6O7KIHHiVJqugCUNmyA5/Ru4PgNDbL4S SsR/aK8sErJk9YO3K/t6ZAjkmiWLeckoxnSWSNnSVKNVOOkFFu87ft6siF/H9OWMeyeW xlDzuWQVVAsIPQ/QgxTF9b6so7xDnrxHsBK+kpeKL4xn8nl7qnwTiRIaxHWCtBVxlYw6 c/ng== MIME-Version: 1.0 Received: by 10.68.223.161 with SMTP id qv1mr2063229pbc.100.1333046074660; Thu, 29 Mar 2012 11:34:34 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.52.40 with HTTP; Thu, 29 Mar 2012 11:34:34 -0700 (PDT) In-Reply-To: <20120329182847.GD2358@deviant.kiev.zoral.com.ua> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> <20120329091415.GA1316@reks> <20120329093427.GA2358@deviant.kiev.zoral.com.ua> <20120329182847.GD2358@deviant.kiev.zoral.com.ua> Date: Thu, 29 Mar 2012 11:34:34 -0700 X-Google-Sender-Auth: Y9Bwm7peO2ax0PGduNc6nXm-lA0 Message-ID: From: mdf@FreeBSD.org To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org Subject: Re: RFC: SEEK_HOLE/SEEK_DATA common implementation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:34:35 -0000 On Thu, Mar 29, 2012 at 11:28 AM, Konstantin Belousov wrote: > On Thu, Mar 29, 2012 at 06:56:31AM -0700, mdf@freebsd.org wrote: >> On Thu, Mar 29, 2012 at 2:34 AM, Konstantin Belousov >> 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. =A0For >> OneFS, a call to VOP_BMAP is fatal. =A0That 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 implementat= ion > 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