> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Frank Contrepois
>
> r...@fsbu ~# zfs destroy fsbu01-zp/mailbo...@zfs-auto-snap:daily-2010-
> 04-14-00:00:00
> cannot destroy 'fsbu01-zp/mailbo...@zfs-auto-snap:daily-2010-04-14-
> 00:00:00': d
A little work with dtrace, please be kind, this is my first post and first
dtrace work
PRESENTATION
r...@fsbu ~# uname -a
SunOS fsbu 5.10 Generic_142901-06 i86pc i386 i86pc
r...@fsbu ~# zfs list -r fsbu01-zp/mailboxes
NAME USED AVAIL
REF
On 01/04/2010 02:01, Charles Hedrick wrote:
So we tried recreating the pool and sending the data again.
1) compression wasn't set on the copy, even though I did sent -R, which is
supposed to send all properties
2) I tried killing to send | receive pipe. Receive couldn't be killed. It hung.
3) T
On 01/04/2010 15:24, Richard Elling wrote:
On Mar 31, 2010, at 7:57 PM, Charles Hedrick wrote:
So that eliminates one of my concerns. However the other one is still an issue.
Presumably Solaris Cluster shouldn't import a pool that's still active on the
other system. We'll be looking more
On Wed, 31 Mar 2010, Charles Hedrick wrote:
3) This is Solaris Cluster. We tried forcing a failover. The pool
mounted on the other server without dismounting on the first. zpool
list showed it mounted on both machines. zpool iostat showed I/O
actually occurring on both systems.
This is a goo
On Mar 31, 2010, at 7:57 PM, Charles Hedrick wrote:
> So that eliminates one of my concerns. However the other one is still an
> issue. Presumably Solaris Cluster shouldn't import a pool that's still active
> on the other system. We'll be looking more carefully into that.
Older releases of Sola
On Mar 31, 2010, at 7:51 AM, Charles Hedrick wrote:
> We're getting the notorious "cannot destroy ... dataset already exists". I've
> seen a number of reports of this, but none of the reports seem to get any
> response. Fortunately this is a backup system, so I can recreate the pool,
> but it's
On 04/ 1/10 02:01 PM, Charles Hedrick wrote:
So we tried recreating the pool and sending the data again.
1) compression wasn't set on the copy, even though I did sent -R, which is
supposed to send all properties
Was compression explicitly set on the root filesystem of your set?
I don't t
So that eliminates one of my concerns. However the other one is still an issue.
Presumably Solaris Cluster shouldn't import a pool that's still active on the
other system. We'll be looking more carefully into that.
--
This message posted from opensolaris.org
_
Ah, I hadn't thought about that. That may be what was happening. Thanks.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On 04/ 1/10 02:01 PM, Charles Hedrick wrote:
So we tried recreating the pool and sending the data again.
1) compression wasn't set on the copy, even though I did sent -R, which is
supposed to send all properties
2) I tried killing to send | receive pipe. Receive couldn't be killed. It hung.
So we tried recreating the pool and sending the data again.
1) compression wasn't set on the copy, even though I did sent -R, which is
supposed to send all properties
2) I tried killing to send | receive pipe. Receive couldn't be killed. It hung.
3) This is Solaris Cluster. We tried forcing a fai
# zfs destroy -r OIRT_BAK/backup_bad
cannot destroy 'OIRT_BAK/backup_...@annex-2010-03-23-07:04:04-bad': dataset
already exists
No, there are no clones.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.o
On 04/ 1/10 01:51 AM, Charles Hedrick wrote:
We're getting the notorious "cannot destroy ... dataset already exists". I've
seen a number of reports of this, but none of the reports seem to get any response.
Fortunately this is a backup system, so I can recreate the pool, but it's going to take
On 31-3-2010 14:52, Charles Hedrick wrote:
> Incidentally, this is on Solaris 10, but I've seen identical reports from
> Opensolaris.
>
Probably you need to delete any existing view over the lun you want to
destroy.
Example :
stmfadm list-lu
LU Name: 600144F0B67340004BB31F060001
stmfad
Incidentally, this is on Solaris 10, but I've seen identical reports from
Opensolaris.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
We're getting the notorious "cannot destroy ... dataset already exists". I've
seen a number of reports of this, but none of the reports seem to get any
response. Fortunately this is a backup system, so I can recreate the pool, but
it's going to take me several days to get all the data back. Is t
17 matches
Mail list logo