Date: Tue, 30 Apr 1996 12:58:51 -0700 From: DARREND@novell.com (Darren Davis) To: freebsd-fs@freebsd.org, pvh@leftside.its.uct.ac.za, DARREND@novell.com, merblich@ossi.com, merblich@ossi.com Subject: Re: Compressing filesystem: Technical issues - Reply - Reply Message-ID: <s1860c6f.087@fromGW>
next in thread | raw e-mail | index | archive | help
I guess I didn't catch the part about being compressed in the background. I was thinking more along the lines of having a utility that would compress the file on demand. The compression would be at the vnode layer so that all my standard utilities would do ordinary read and writes to the vnode layer and get uncompressed data. Then in order to inspect what files are compressed, I would change ls and the file metadata so that a z would appear in the left most column as follows: bash$ ls -l bin total 12 zrwxr-xr-x 1 darrend darrend 85 Apr 5 16:29 acroread zrwxr-xr-x 1 darrend darrend 78 Feb 15 14:44 title -rwxr-xr-x 1 darrend darrend 74 Apr 2 14:54 wordview bash$ The files acroread and title are compressed, wordview is not. Having a compress on demand utility would allow me to setup a script to peruse the tree and find files of a certain age and compress them. Once compressed I should have smaller I/Os since less blocks would be used. I guess I am visioning a compress layer so that I don't have the usuall block compression problem of trying to guess how much space this file is going to take when compressed (most just guess that 2:1 is average). So what I would have is something not much different the gzip with the benefit of having it transparent through the vnode layer so that my legacy utilities don't have to pipe through gzip. Of course this has the BIG problem that the whole file would need to be uncompressed when used, making this problematic with large files. Though I guess I still believe in the data that shows the average file size to still be 22K. As for large files, things like mpeg streams and jpegs are compressed anyway so you never relize a benefit anyway. This is why I prefer compress on demand to having a background compression based on file age. Just my thoughts, (and most likely flawed). Darren R. Davis Senior Software Engineer Novell, Inc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s1860c6f.087>