Broke the mirror and tried to a single drive and the backup worked; the
combination of USB and e-sata was obviously upsetting it.
If only this Marvel chipset was supported then I could get the second
e-sata channel working. Ah well.
After the backup was complete I have tried reconnecting and
I've been seeing a ton of messages like:
Jun 11 08:59:08 nas Log info 0x31120303 received for target 9.
Jun 11 08:59:08 nas scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc
Jun 11 08:59:08 nas scsi: [ID 365881 kern.info]
/pci@0,0/pci8086,27d0@1c/pci1000,3040@0 (mpt_sas10):
root
Hello all,
In OpenSolaris and its descendants it is possible to create
local zones (LZ) which share an IP stack with the global zone
(GZ) or have an exclusive IP stack. While exclusive stacks
have better separation between zones, the shared stacks may
yield higher performance comparable to
thanks, i got it. unfortunately, the solaris x86 executable doesn't seem to
run under openindiana. Here is the result:
root@nas:/tank/windows/dswartz# file sas2ircu
sas2ircu: ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, stripped
root@nas:/tank/windows/dswartz# ./sas2ircu
I added that because I have a folder with the Win32/Linux x86/Solaris
x86 binaries all in it; it should be the same file you have.
I'm wondering if there's any problems with executing binaries from the
FS or user you were?
- Rich
On Mon, Jun 11, 2012 at 10:40 AM, dswa...@druber.com wrote:
I would guess the error you're having involves the devices having
different block sizes.
# ./smartctl -d sat -i /dev/rdsk/c7t5000C5003886DDA4d0s0
smartctl 5.42 2011-10-20 r3458 [i386-pc-solaris2.11] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
===
I added that because I have a folder with the Win32/Linux x86/Solaris
x86 binaries all in it; it should be the same file you have.
I'm wondering if there's any problems with executing binaries from the
FS or user you were?
I was running as root. I ssh'ed to the OI box, ran 'sudo -i' and
I added that because I have a folder with the Win32/Linux x86/Solaris
x86 binaries all in it; it should be the same file you have.
I'm wondering if there's any problems with executing binaries from the
FS or user you were?
I seem to recall you see that Killed behavior when there is something
Ah, I think I know what happened. It didn't seem to want me to execute it
while it was on that cifs shared dataset. No idea why. I copied it to a
system directory and it runs fine now. Go figure. Now I need to figure out
how to use it to figure out what Target 9 is...
-Original
Hmmm, nothing obvious leaps out. Looking at output from sasinfo command:
sasinfo target-port -v
Target Port SAS Address: 50014ee204411a53
Type: SATA Device
HBA Port Name: /dev/cfg/c13
Expander Device SAS Address: None (Failed to Get Attached Port)
Target Port SAS Address:
Someone posted this comment about my description of the problem on YouTube.
Anyone care to comment please?
nope I don't think it does, I think you experiencing 4K and Advance
Format compatibility issues. The solution is a patched version of
zpool. I am not so sure that OpenIndiana has been
Fantastic job!
Thanks!
On Fri, Jun 8, 2012 at 9:46 AM, Paolo Marcheschi
paolo.marches...@ftgm.itwrote:
Hi
here they are :
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/13.0/contrib/so
laris_pkgadd/
2012-06-11 18:19, Dan McDonald wrote:
2012-06-11 18:47, Sebastien Roy wrote:
DAN The fundamental question is always: What problem are you really
trying to solve?
And as always (or often), it is a valid question.
Technically, there is no immediate problem that I'd solve only
this way, or,
2012-06-11 21:16, michelle wrote:
Someone posted this comment about my description of the problem on YouTube.
Anyone care to comment please?
nope I don't think it does, I think you experiencing 4K and Advance
Format compatibility issues. The solution is a patched version of
zpool. I am not so
2012-06-11 18:19, Dan McDonald wrote:
The fundamental question is always: What problem are you really trying to
solve?
Okay, I found another rationale beside performance and simplified
intra-zone routing (though not as apparent as exclusive routing).
It seems that the shared IP stack offer
Thanks, Jim! The WWN would be good enough, since all my drives (in the data
pool anyway) have the WWN printed on the top :)
-Original Message-
From: Jim Klimov [mailto:j...@cos.ru]
Sent: Monday, June 11, 2012 3:08 PM
To: Discussion list for OpenIndiana
Cc: Dan Swartzendruber
Subject:
2012-06-11 22:57, Robert Mustacchi wrote:
This isn't a problem. When you promiscuously sniff traffic on a VNIC
regardless of zone, you only get the following:
* unicast traffic with your zones MAC address
Okay, one problem less, maybe
* Broadcast and multicast traffic
This might expose some
Jim Klimov wrote:
2012-06-11 18:19, Dan McDonald wrote:
The fundamental question is always: What problem are you really
trying to solve?
Okay, I found another rationale beside performance and simplified
intra-zone routing (though not as apparent as exclusive routing).
It seems that the
James Carlson wrote:
For what it's worth (and having worked on the code in the now-distant
past), I certainly agree with you at a high level. What you're
describing is an obvious generalization of the exclusive stack
concept. It was obvious enough that we actually discussed it
internally
On 12/06/12 08:39 AM, Hans J. Albertsson wrote:
Suppose:
I have a system with but two disks. They're fairly small: 300GB, and use 512B
sectors.
These two disks are a mirror zpool, creqated from the entire disks.
There are about 20 or so filesystems in there.
The system has room for only two
Won't zpool replace fail b/c the new disks require ashift=12 and his
existing pool devices have ashift=9?
- Rich
On Mon, Jun 11, 2012 at 7:12 PM, James C. McPherson
james.c.mcpher...@gmail.com wrote:
On 12/06/12 08:39 AM, Hans J. Albertsson wrote:
Suppose:
I have a system with but two
On 12/06/12 09:16 AM, Rich wrote:
Won't zpool replace fail b/c the new disks require ashift=12 and his
existing pool devices have ashift=9?
I have no idea. I don't think it's too much of a stretch to
assume that an error provided during zpool replace would result
in a quick response to the
On Jun 11, 2012, at 6:08 PM, Bob Friesenhahn wrote:
On Mon, 11 Jun 2012, Jim Klimov wrote:
ashift=12 (2^12 = 4096). For disks which do not lie, it
works properly out of the box. The patched zpool binary
forced ashift=12 at the user's discretion.
It seems like new pools should provide the
On Tue, Jun 12, 2012 at 12:50 AM, Richard Elling
richard.ell...@richardelling.com wrote:
On Jun 11, 2012, at 6:08 PM, Bob Friesenhahn wrote:
On Mon, 11 Jun 2012, Jim Klimov wrote:
ashift=12 (2^12 = 4096). For disks which do not lie, it
works properly out of the box. The patched zpool binary
24 matches
Mail list logo
