Date: Mon, 6 Mar 95 11:12:13 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: current@freefall.cdrom.com, jkh@FreeBSD.org Subject: Re: "Sparse" files? Message-ID: <9503061812.AA18693@cs.weber.edu> In-Reply-To: <199503060641.QAA15475@godzilla.zeta.org.au> from "Bruce Evans" at Mar 6, 95 04:41:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Do we have any support for the likes of Linux's sparse files? Patrick > >here says it saves around 25% for executables alone when run-length > >compression is done for zero'd blocks. > > ffs certainly supports holes in regular files. Gnu cp preserves holes > in regular files and creates them if possible, at least on POSIX file > systems for which stat() returns suitable non-POSIX info (st_blocks > and/or st_blksize). Our cp neither creates them nor preserves them. > It might be difficult to support them and still use mmap(). > > The usual ffs block size is 8K, while the usual linux block size is 1K, > so the chance of finding a zero block to compress is much lower. What they are doing is RLE "compression", so it isn't really a "sparse" file. BSD has (?) gzip support anyway. I was thinking on the zero'ed block issue last night, both in regard to frags being zeroed, and in regard to alignment and restoration issues. The alignment issue would allow paging on a 512 byte boundry. This is a clear win in the file-as-swap-store case. The restoration issue is one of special casing zero-fill block writes to not mark the block dirty for written zeroes. Clearly, you could do this in copy (like gnu cp and tar currently do); the question is whether the kernel write overhead is too high. One of the guys at work has been experimenting with using "team" to download images on an http server with some significant promise; this is related, in that it implies that the amount of time in an I/O wait is sufficient latency to mask overhead in a block compare for 0's, at least until kernel multithreading and reader/writer locking are pounded in everywhere. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503061812.AA18693>