Date: Fri, 19 Feb 2010 16:36:40 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: GEOM_ULZMA Message-ID: <hlmb66$n0t$1@ger.gmane.org> In-Reply-To: <20100219163644.da89e882.ray__27111.9062825621$1266591431$gmane$org@dlink.ua> References: <20100219163644.da89e882.ray__27111.9062825621$1266591431$gmane$org@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/19/10 15:36, Alexandr Rybalko wrote: > Hi, > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in connection with this is an issue best left lzma One of the (relatively) unexpected problems with such block-level compression is its efficienty - since you need to compress individual blocks to be seekable (if you are not designing a special algorithm), the compression ratios tend to not increase in a big way as the algorithm improves. It would be interesting to see a comparison of sizes with geom_uzip if you have them. > code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better? The code organization depends on what you want to do with it and how you want to update the code in the future, if your lzma library is third party. If you never intend to update the lzma code then I guess it's fine to embed it in a big .c file. For a port, it doesn't matter much since it is your own thing. There are stricter rules on maintainability and style if you want it in the base system. > Maybe in future make lzma and gzip library kernel interface for embedded? > Then in one instance of code, userland can use compression via kernel. This never happens now (I mean userland calling into the kernel for compression) so you will need to explain the benefits first (kernel code is not magically faster than userland - it runs on the same CPU).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hlmb66$n0t$1>