From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: File perforation. Date: Wed, 08 Jan 2003 23:14:59 +0000 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <23586.1042067699@passion.cambridge.redhat.com> References: <3E1CAC90.6050303@inet.com> <3E1CA628.7000002@inet.com> <21551.1042063560@passion.cambridge.redhat.com> <22288.1042065284@passion.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: In-Reply-To: <3E1CAC90.6050303@inet.com> To: Eli Carter List-Id: linux-fsdevel.vger.kernel.org eli.carter@inet.com said: > On a compressed fs like jffs2, wouldn't a block of 0's compress down > to next-to-nothing already? Well, sort of. In fact each page would get zlib-compressed down to about 40-odd bytes of payload and a datanode header of 70-odd bytes. > Can the fs recognize a big block of 0's and make it sparse on-the-fly > without needing the user to specify it? (On block-based fs's, that > might not always be desirable due to out-of-space errors on modifying > a file, but for a compressed fs, that's not a new issue.) Yeah -- JFFS2 has a special compression type for a datanode payload which is all zeroes, but doesn't currently _detect_ that in a write, it only gets used for holes. 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 suppose we could always compare _after_ zlib compression though :) The other thing about hole nodes (i.e. nodes with this special compression type and hence no actual compressed data payload on the medium) is that they're an exception to the rule that data nodes may not cross a page boundary. So when we write zeroes to a file, even if we fix the compression to notice and use JFFS2_COMPR_ZERO instead of zlib hence have no data payload on the nodes, we still get a 70-odd-byte node header for every (typ.) 4KiB, whereas with a 'proper' hole we'd write out a single node to cover the whole range. I suppose we could also munge the garbage collection to notice adjacent hole nodes and merge them... on the whole, I think I prefer sys_perforate() though. -- dwmw2