Re: File perforation.

[David Woodhouse <dwmw2@infradead.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