From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: File perforation. Date: Wed, 08 Jan 2003 17:22:59 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3E1CCEF3.3409DCED@digeo.com> References: <3E1CAC90.6050303@inet.com> <23586.1042067699@passion.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Eli Carter , linux-fsdevel@vger.kernel.org Return-path: Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id RAA23009 for ; Wed, 8 Jan 2003 17:23:00 -0800 (PST) To: David Woodhouse List-Id: linux-fsdevel.vger.kernel.org David Woodhouse wrote: > > I was dubious about adding a check for all zeroes before > falling back to zlib, since it'll slow down the common case where we write > non-zero data. I suggest you bench this first. As a prototype, just add some code to touch the data and see how much difference it makes. Quite possibly not much - view it as a fancy cache preload. Plus for real data, it'll bale out after the first byte... A full holepunch()/perforate() thing is, as Dave points out, a trickier version of truncate. It's quite a hassle for not a lot of gain on the block filesystems.