On 9/3/07, Dale Ghent <[EMAIL PROTECTED]> wrote:
>
> I saw a putback this past week from M. Maybee regarding this, but I
> thought I'd post here that I saw what is apparently an incarnation of
> 6569719 on a production box running s10u3 x86 w/ latest (on
> sunsolve) patches. I have 3 other servers
I'm trying to use the Microsoft iSCSI initiator against a target on a ON build
70 box. This target is a RAID Z volume with seven 750 gig drives, in an Ultra
40 M2. I can create the ZFS pool just fine and mount it, and can also create a
4 TB iSCSI target on that pool. When I try to connect to it
Yes, this would be useful. See:
6364688 method to preserve properties when making a clone
The infrastructure is all there (zfs_clone() takes an nvlist of
properties), it just hasn't been implemented yet.
Note that 'volblocksize' is special because it is a create-time property
and cannot be chan
I had expected that when I clone'd a snapshot properties like
"compression" would be "copied" over to the clone from the parent
snapshot regardless of the inheritance implied from the place in the
tree. Particularly since 'zfs clone' doesn't have the ability to
set options. However it seems t
Yesterday I tried to clone a xen dom0 zfs root filesystem and hit this panic
(probably Bug ID 6580715):
System is running last week's opensolaris bits (but I'm also accessing the zpool
using the xen snv_66 bits).
files/s11-root-xen: is an existing version 1 zfs
files/[EMAIL PROTECTED]: new snap
I saw a putback this past week from M. Maybee regarding this, but I
thought I'd post here that I saw what is apparently an incarnation of
6569719 on a production box running s10u3 x86 w/ latest (on
sunsolve) patches. I have 3 other servers configured the same way WRT
work load, zfs pools
