Hello, Does the work of IEEE''s Security in Storage Working Group [1] have any affect on the design of ZFS''s encryption modules? Or do the two efforts deal with different "layers"? Seems that 1619 is more geared towards SAN disks, where ''regular'' file systems tend to sit on and not know that they''re on. Most other file systems (and the current, public, ZFS implementation) also don''t support encryption. So would it be possible to ''wedge'' the encryption between ZFS and the actual spinning disk via the SAN controller? Would that affect the workings of ZFS checksums, etc.? AFAICT, the encryption is supposed to be transparent to the higher layers above the SAN. Thanks for any info. Regards, David [1] http://siswg.org/
David Magda wrote:> Hello, > > Does the work of IEEE''s Security in Storage Working Group [1] have any > affect on the design of ZFS''s encryption modules? Or do the two efforts > deal with different "layers"?See the draft design doc on the ZFS crypto page: http://www.opensolaris.org/os/project/zfs-crypto/> Seems that 1619 is more geared towards SAN disks, where ''regular'' file > systems tend to sit on and not know that they''re on. Most other file > systems (and the current, public, ZFS implementation) also don''t support > encryption. So would it be possible to ''wedge'' the encryption between > ZFS and the actual spinning disk via the SAN controller?Thats not the best way to do it to complement ZFS current capabilities. As you should see, and if you don''t let me know, from the draft design doc checksum/compression/crypto all happen at the same layer (ZIO) of the ZFS stack. -- Darren J Moffat