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
