From owner-freebsd-fs@FreeBSD.ORG Thu Mar 29 09:14:20 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 31B5B106566C for ; Thu, 29 Mar 2012 09:14:20 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF8DE8FC17 for ; Thu, 29 Mar 2012 09:14:19 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2282116bkc.13 for ; Thu, 29 Mar 2012 02:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0EwvKQens6xOxttbRIo2p4YzNPcRAOsUArdNNZjgaNY=; b=sphCwdCnj16WCN6A/An764x7tbSxZx+wnv3CBJ1TAjPwOZcM6y7jC5wVmnj1scI7HX MVJkqSTrw5Zfu/jodjQbN7MXn8K6j45SYeMf8BgTTiRJd9/EzBQQJYPKSN7ujbMyUufX L7HPL5kVxz2p4WdX6OHTMPrMLI8dxkfq0NNDS/PeaZYl3s1dhnq7FNQagDtnaO4JH5Jr OqmIHUg5tskCVXW0zzpCAQKcHdX8pSbSHX23azfemIQWuogyVkGtvwUW0SiXG7Kngd+d D5ONaSyPMNekBbq0G7+8ZYaH1WI1lYhmdpqfBlGYaZinhCPV9aYhFHl0cFu00bBeFjJt Tqow== Received: by 10.204.154.83 with SMTP id n19mr6251024bkw.69.1333012458458; Thu, 29 Mar 2012 02:14:18 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id u5sm12189593bka.5.2012.03.29.02.14.16 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 02:14:17 -0700 (PDT) Date: Thu, 29 Mar 2012 12:14:15 +0300 From: Gleb Kurtsou To: Konstantin Belousov Message-ID: <20120329091415.GA1316@reks> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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 09:14:20 -0000 On (27/03/2012 21:34), Konstantin Belousov wrote: > Hello, > Please find at > http://people.freebsd.org/~kib/misc/seek_hole.1.patch > a prototype generic implementation of the SEEK_HOLE/SEEK_DATA lseek(2) > whence command for any filesystem that properly supports bmap. > > I was unable to find any test suite for the feature, and the only more > or less reasonable case I found was from lklm, extracted at > http://people.freebsd.org/~kib/misc/seek_hole.c > The block for file with hole at the end is commented out because > UFS never puts holes at EOF. The block_size is tuned for default block > size on UFS on recent FreeBSD. > > Filesystem-specific implementations could greatly increase the performance > of the call, because the presented implementation does linear search > through the blocks until hole/data boundary is found. E.g., for UFS, > the fast tree-like structure of indirect blocks can be traversed to > point at the next boundary. But this implementation is generic. What do you think about replacing FIOSEEKHOLE/FIOSEEKDATA ioctls with VOP_SEEKHOLE (or similar). That would be more straightforward. Currently there is no way for a file system to use standard SEEKHOLE implementation without invoking vop_stdioctl. It handles only FIOSEEKHOLE now but that is likely to change in future. I wish we had no default VOP_IOCTL implementation and keep it file system specific. We should also return valid _PC_MIN_HOLE_SIZE (=mnt_stat.f_iosize) in VOP_PATHCONF for userland to see SEEK_HOLE/SEEK_DATA support. I'm not sure enabling it by default is desirable, performance penalty can be considerable. Consider creating tar archive of large files with O(file size) SEEK_HOLE enabled. On the other hand default implementation can be useful, e.g. if file system had internal flag for sparse files it could simply reuse default vop_stdseekhole() avoiding overhead for non-sparse files. Thanks, Gleb. > > Please comment.