From owner-freebsd-fs@FreeBSD.ORG Mon Mar 7 18:50:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9791106566B; Mon, 7 Mar 2011 18:50:52 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 660458FC17; Mon, 7 Mar 2011 18:50:51 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id D1835756E04; Mon, 7 Mar 2011 19:50:49 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 21.5977] X-CRM114-CacheID: sfid-20110307_19504_BDAD6C73 X-CRM114-Status: Good ( pR: 21.5977 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Mar 7 19:50:49 2011 X-DSPAM-Confidence: 0.9961 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4d752909698301593421374 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+I, 0.00104, >+I, 0.00104, >+On, 0.00120, wrote+>, 0.00208, struct, 0.00212, struct, 0.00212, >>+>>, 0.00239, >>+>>, 0.00239, >+>, 0.00262, wrote+>>, 0.00323, is+>, 0.00343, NULL), 0.00366, error+=, 0.00422, wrote, 0.00442, wrote, 0.00442, files+with, 0.00499, enabled, 0.00548, enabled, 0.00548, h>, 0.00548, all+>, 0.00548, I+guess, 0.00609, I+guess, 0.00609, #ifdef, 0.00685, files, 0.00740, files, 0.00740, X-Spambayes-Classification: ham; 0.00 Message-ID: <4D752909.3050503@fsn.hu> Date: Mon, 07 Mar 2011 19:50:49 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4D710154.90409@fsn.hu> <20110306084217.GA9791@garage.freebsd.pl> In-Reply-To: <20110306084217.GA9791@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Punching holes into (sparse) files - porting Solaris fcntl(F_FREESP) to FreeBSD? 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: Mon, 07 Mar 2011 18:50:53 -0000 On 03/06/2011 09:54 AM, Pawel Jakub Dawidek wrote: > On Fri, Mar 04, 2011 at 04:12:20PM +0100, Attila Nagy wrote: >> Hi, >> >> Is it possible to make regions of files, with already written data >> sparse? (I'm interested to do this on ZFS) >> >> All I could find in this topic is: >> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg29047.html >> >> grepping through the source gives a match for VOP_SPACE in >> cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c: >> zfs_replay_truncate(zfsvfs_t *zfsvfs, lr_truncate_t *lr, boolean_t byteswap) >> { >> #ifdef sun >> [...] >> error = VOP_SPACE(ZTOV(zp), F_FREESP,&fl, FWRITE | FOFFMAX, >> lr->lr_offset, kcred, NULL); >> >> And the relevant section from fcntl(2) in Solaris: >> F_FREESP >> >> Free storage space associated with a section of the >> ordinary file fildes. The section is specified by a >> variable of data type struct flock pointed to by arg. >> The data type struct flock is defined in the >> header (see fcntl.h(3HEAD)) and is described below. Note >> that all file systems might not support all possible >> variations of F_FREESP arguments. In particular, many >> file systems allow space to be freed only at the end of >> a file. >> >> F_FREESP seems to be my friend, and it's implemented in Solaris's ZFS. >> How hard would it be to complete the port and make it accessible from >> FreeBSD? >> I guess it was left out with a reason... > Well, adding new VOP is important decision. We could eventually > implement this via ioctl(2), I think... This is a nice feature after all. > > I don't know why do you need this, but note that when compression is > enabled on a ZFS file system, all-zeros blocks are turned into holes, so > if you do have compression enabled and you write all zeros in the place > you want to punch a hole, the pool space should be reclaimed. > I would like to use it for integer-indexed fixed size storage, where the given block can be accessed by multiplying the block size with the index number. A sparse file would allow to reclaim freed blocks' space. But with SEEK_HOLE and SEEK_DATA, and the promised efficiency of sparse files on ZFS I guess there are a lot more use cases than before (for sparse files). Thanks for the info about compression, I didn't know that. Should I assume that using compression and writing blocksize number of zeroes is efficient as F_FREESP? Thanks,