On Jan 31, 2007, at 9:04 PM, Moinak Ghosh wrote:
> Dave Miner wrote:
>> james hughes wrote:
>>> Does ZFS have a feature that allows diffs to be placed another
>>> space? This would be valuable to Xen clients where all the
>>> clients are booted off the same golden master.
While not the same thing, Sun (actually the old StorageTek) did a
similar thing for z390 Linux.
http://www.storagetek.com/upload/product_collateral/current/75/555.pdf
creating "Mainframe Linux with Shared Virtual Array disk system and
SnapVantage software: Commanding the Linux army of servers in the z/VM
environment"
>> While we need to have much more conversation with the Xen project
>> about the topic, I think we'd agree that their current usage model
>> for that scenario based on the diskless client setup would be
>> vastly improved by using ZFS clones, which do a form of "another
>> space". I suspect you're suggesting a much more flexible
>> redirection than ZFS clones allow, in which case UnionFS or its ilk
>> might be helpful.
Yes, documentation for VMware clones is at
http://www.vmware.com/pdf/ws5_clones_technote.pdf
which is interesting. See attached picture....
I am not suggesting an implementation as much as opening up the
possibilities.
>> But I still wonder at that point if the complications (and
>> resulting costs) there are worse long-term than spending some time
>> re-thinking how the system is put together to make such overlay
>> machinery unnecessary to get "another space" for the pieces which
>> truly need it. Would probably be interesting for someone to start
>> playing with the FunionFS stuff from FUSE (assuming we have that
>> working) just to understand how it might fit.
There is a project for FUSE, but that may or may not be applicable.
http://www.opensolaris.org/os/project/fuse/
> Another wild idea: Extend the zpool framework to handle a mix of
> read-only and
> writable devices. The pool can be imported initially from a R/O
> device with a R/W
> device being added later on. The R/W device can host writable
> clones of
> filesystems on the R/O device thus providing UnionFS like behavior
> but being
> much more time and space efficient.
Interesting, yes.
Jim
> Regards,
> Moinak.
>
>>
>> Dave
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 1.png
Type: image/png
Size: 33114 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20070131/799848b1/attachment.png>
