From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: how do plugins work? Date: Sat, 26 Oct 2002 19:46:24 +0400 Message-ID: <3DBAB8D0.904@namesys.com> References: <3DB81095.25F0C662@namesys.com> <3DB8816C.10400@namesys.com> <3DB950B8.611CC982@namesys.com> <3DB9DE71.7000503@namesys.com> <3DBAA71B.667E2EE8@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Edward Shishkin Cc: gregor@zeitlinger.de, reiserfs mailing list Edward Shishkin wrote: >Hans Reiser wrote: > > >>Edward Shishkin wrote: >> >> >> >>>Hans Reiser wrote: >>> >>> >>> >>> >>>>Edward Shishkin wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Gregor Zeitlinger wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>I'm new to this list. I'm wondering how the file plugins work. Are they >>>>>>just a means of accessing the file contents or are they also designed to >>>>>>save the file differently. >>>>>> >>>>>>For example, could you create a plugin that automatically zips each >>>>>>text/plain file, which is totally transparent to the user? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Yeah, we could. Although transparentness means a bit worse compression.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>? >>>> >>>>You mean because of choosing to use compression atoms >>>> >>>> >>>> >>>> >>>Yes, but it is not the only reason. >>> >>> >>> >>> >>> >>>>that are node sized? >>>> >>>> >>>> >>>> >>>No, compression atoms are limited by common sense ;) >>>Obviously, it doesn't make sense to choose it less then node size, if you >>>want to compress a file presented by tails. On the other hand, I am not >>>sure if you will be delighted from transparent compression supported by 256K >>>clusters even for larger files. >>> >>> >>> >>> >>> >>>>Maybe it might be more precise to say that efficient random >>>>access motivates small compression atoms which are less efficient? >>>>(Assuming that I understood you.) >>>> >>>> >>>> >>>> >>>There is one more obscured reason that makes transparent compression worser. >>>I have to remind that its primary assignment is the same: to provide more >>>efficient disk space usage. Let's take a look how transparent compression >>>and the package using the same compression algorithm will provide it: >>>Suppose we want to compress a 8S-byte file, and both transparent compression >>>and package is supported by 4-blocks clusters, S - block size. >>> >>>File system: >>>divides the file into 2 clusters, suppose each cluster was compressed up to >>>(2S+1) bytes, so compressed file occupies 6 blocks. >>>Package: >>>makes compressed file which occupies 2*(2S+1) = 4S+2 bytes and passes it >>>to the file system, which places it (aieee!) into 5 blocks.. >>> >>> So we do have the actual compression ratio produced by the file system is >>>6/8 = 25% against actual ones (5/8 = 37,5%) produced by the package. The user >>>can observe this effect only by using "du" (when he does "df", he see that >>>file system and package produce the same compression ratio 37,5%). >>>This is another effect caused by the specific of packing policy (for the >>>ext2 files, reiserfs files presented by indirect items, etc..) Obviously >>>we can avoid this by using bigger cluster (8 blocks). >>> >>>Edward. >>> >>> >>> >>> >>> >>> >>Or by not block aligning the clusters, which might be the right >>solution, >> >> > >It is impossible for the files presented by indirect items, since >it means you'll place dead space in memory per file. > We don't use indirect items. It is not impossible in any event, the problem is with being efficient in reads while also ensuring that we read whole compression atoms at a time. > > > >>and might allow for compression atoms larger than nodes. >> Please consider that approach. >> >>Hans >> >> > > > >