Re: [zfs-discuss] Can ZFS be event-driven or not?

2008-02-27 Thread Lally Singh
Hmm, two thoughts on this:

1. For anyone interested, didn't VMS do something like this?  Perhaps
a look at its design and implementation would be useful here.

2. For the per-application issue, there are ways to handle that.
First, make a ZFS api for providing file-level snapshots.  Then, a
library wrapper around the normal syscalls (open,close,read,write,etc)
that invokes the zfs apis as needed.  Either the wrapper is smart
enough to know which app wants which behavior (perhaps even
specializing also on the path of the file), or several libraries
available for different tasks.  Shove it/them in something like
LD_PRELOAD and you'd be good to go.

As for utility, I think this sort of thing would be fantastic in
certain areas.  If you can develop the feature set cheap enough, then
it's a real win.  I haven't touched ZFS's internals (in code or even
dev docs), so I don't know what kind of work's required to pull off
file-level snapshots.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Mac OS X 10.5.0 Leopard ships with a readonly ZFS

2007-10-30 Thread Lally Singh
On 10/30/07, Joe Richards <[EMAIL PROTECTED]> wrote:
> I'm also very interested in getting this going, it's frustrating having Apple 
> ignore what a big selling point for Leopard this is!
>

Check out the Mac blogosphere.  I think Apple's waiting until ZFS's
got a few more things ironed out.  The big concerns seem to be massive
bulk I/O for video, maybe more reliability/testing on their part.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS Crypto Alpha Release

2007-10-22 Thread Lally Singh
A few things come to mind:
* Attaching a label to the zfs filesystem, so I can't mount the FS in
an unlabeled or differently-labeled zone if I don't want to.
(multiple labels for shared fs's would be cool, too.)
* Connecting the startup of the trusted zone (I'm still learning this
stuff, sorry if I'm completely off) to the mounting of the filesystem
-- I guess these two are similar, in enforcing access to the
restricted data to the restricted environment.  Perhaps requiring the
keys to the fs's as the zone boots.
* Straightforward setup to set them both up together.

On a portable or an easy-to-steal desktop, the trusted zone's don't
help me much without an encrypted store for it.  Encrypted ZFS is
useful by itself, but trusted zones with a disk that can get stolen
needs encryption.

Optimally, that mind-boggling 2-line setup procedure for my ZFS setup
would be the model for setting up both a zfs encrypted store & a
trusted zone atop of it.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS Crypto Alpha Release

2007-10-20 Thread Lally Singh
Looks great.. Any (long-term distant-future) plans of integrating this with the 
Trusted Extensions for a real quick setup?  With a check to make sure the key's 
password != the label, just to be sure :-P
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss