From owner-freebsd-fs@FreeBSD.ORG Thu Mar 29 13:56:32 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACC0A1065672 for ; Thu, 29 Mar 2012 13:56:32 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 65B1B8FC1D for ; Thu, 29 Mar 2012 13:56:32 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1767915ggn.13 for ; Thu, 29 Mar 2012 06:56:31 -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; bh=HlkLGfabG/IXrk7NDbzx23/WZ8edGB5EE7BxpeTo7BE=; b=wi3aICTiwL5MgHueKZGOh5LUtIZt2F37++UKBaFJlt78M46je0Gexl76ulfS7C2LnL kpysk/XCU+XRqbbuw+79LSRzcm+gQmnKWjJ8VRW2uMYmUb9FDTc2EA2KRujcCHPjX+kM T2CgM3ugS6V5sb0cdbQA03KrTMEyDoKdBMjF3kR37oRN8lwjLa6vXrQVat02O1tD5xDK X/ORYnxRZSUfGK8A7iviYFroHTjzGZGkXTU1mkknb4ybUCQQApQqmGRNCS2lYhP4Ryes /Cq9udRMQliC7QpsB8qU5FBpsz2YJFLQsBCj9AhSSSFuw9Li3dgsftxzQajjJyJrycpU g89w== MIME-Version: 1.0 Received: by 10.68.189.170 with SMTP id gj10mr214586pbc.121.1333029391072; Thu, 29 Mar 2012 06:56:31 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.52.40 with HTTP; Thu, 29 Mar 2012 06:56:31 -0700 (PDT) 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> Date: Thu, 29 Mar 2012 06:56:31 -0700 X-Google-Sender-Auth: -U-DiqKNhUsGkFoA0v5jizPRXOI Message-ID: From: mdf@FreeBSD.org To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 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 13:56:32 -0000 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. 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