I suppose what would have been nice to see, architecturally, was a way to transform data at some part in the pipeline and to be able to specify various types of transforms, be they compression, encryption or something else. But maybe I'm just dreaming without understanding the complexities of what needs to happen on the "inside", such that where these two operations might take place is actually incompatible and thus there is little point of such a generalisation.
You really don't want crypto algorithms to be that pluggable. The reason being with crypto you need to make a very careful choice of algorithm,keylength and mode (CBC vs EBC vs CTR vs CCM vs GCM etc) and that isn't something you want an end admin doing. You don't want them switching from AES-256-CCM to Blowfish-448-CBC because they see 448 is bigger than 128 so therefore more secure.
For compression it wouldn't be such a big deal except for an implementation artifact of how the ZIO pipeline works, it is partly controlled by the compress stage at the moment.
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.
BTW I actually floated the idea of a generic ZTL - ZIO Transform Layer about this time last year (partly in jest because ZTL is the last three on my car registration :-)).
So, for example, if the interface was plugable and Sun only wanted to ship gzip, but I wanted to create a "better" ZFS based appliance than one based on just OpenSolaris, I might build a bzip2 module for the kernel and have ZFS use that by default.
I have to say it because normally I'm all for pluggable interfaces and I don't think the answer should be "its open source just add it" in this case I think that is for now the safer way.
-- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
