My two cents, Assuming that you may pick a specific compression algorithm, most algorithms can have different levels/percentages of deflations/inflations which is effects the time to compress and/or inflate wrt the CPU capacity.
Secondly, if I can add an additional item, would anyone want to be able to encrypt the data vs compress or to be able to combine encryption with compression? Third, if data were to be compressed within a file object, should a reader be made aware that the data being read is compressed or should he just read garbage? Would/should a field in the znode be read transparently that de-compresses already compressed data? Fourth, if you take 8k and expect to alloc 8k of disk block storage for it and compress it to 7k, are you really saving 1k? Or are you just creating an additional 1K of internal fragmentation? It is possible that moving ' 7K of data accross your "SCSI" type interface may give you a faster read/write performance. But that is after the additional latency of the compress on the async write and adds a real latency on the current block read. So, what are you really gaining????? Fifth and hopefully last, should the znode have a new length field that keeps the non-compressed length for Posix compatibility. I am assuming large file support where a process that is not large file aware should not be able to even open the file. With the additional field (unccompressed size) the file may lie on the boundry for the large file open reqs. Really last..., why not just compress the data stream before writing it out to disk? Then you can at least do a file on it and identify the type of compression... Mitchell Erblich ----------------- Darren Reed wrote: > > From: "Darren J Moffat" <[EMAIL PROTECTED]> > ... > > The other problem is that you basically need a global unique registry > > anyway so that compress algorithm 1 is always lzjb, 2 is gzip, 3 is .... > > etc etc. Similarly for crypto and any other transform. > > I've two thoughts on that: > 1) if there is to be a registry, it should be hosted by OpenSolaris > and be open to all and > > 2) there should be provision for a "private number space" so that > people can implement their own whatever so long as they understand > that the filesystem will not work if plugged into something else. > > Case in point for (2), if I wanted to make a bzip2 version of ZFS at > home then I should be able to and in doing so chose a number for it > that I know will be safe for my playing at home. I shouldn't have > to come to zfs-discuss@opensolaris.org to "pick a number." > > Darren > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss