Here it is:
# pstack core.format1
core 'core.format1' of 3351: format
- lwp# 1 / thread# 1
0806de73 can_efi_disk_be_expanded (0, 1, 0, ) + 7
08066a0e init_globals (8778708, 0, f416c338, 8068a38) + 4c2
08068a41 c_disk (4, 806f250, 0, 0, 0, 0) +
On 13 December, 2012 - Jan Owoc sent me these 1,0K bytes:
> Hi,
>
> On Thu, Dec 13, 2012 at 9:14 AM, sol wrote:
> > Hi
> >
> > I've just tried to use illumos (151a5) import a pool created on solaris
> > (11.1) but it failed with an error about the pool being incompatible.
> >
> > Are we now at
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Fred Liu
>
> BTW, anyone played NDMP in solaris? Or is it feasible to transfer snapshot via
> NDMP protocol?
I've heard you could, but I've never done it. Sorry I'm not much help, except
as
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of sol
>
> I added a 3TB Seagate disk (ST3000DM001) and ran the 'format' command but
> it crashed and dumped core.
>
> However the zpool 'create' command managed to create a pool on the whole
> d
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Netherton
>
> At this point, the only thing would be to use 11.1 to create a new pool at
> 151's
> version (-o version=) and top level dataset (-O version=). Recreate the file
> system h
Hey Sol,
Can you send me the core file, please?
I would like to file a bug for this problem.
Thanks, Cindy
On 12/14/12 02:21, sol wrote:
Here it is:
# pstack core.format1
core 'core.format1' of 3351: format
- lwp# 1 / thread# 1
0806de73 can_efi_disk_be_ex
We have found mbuffer to be the fastest solution. Our rates for large
transfers on 10GbE are:
280MB/smbuffer
220MB/srsh
180MB/sHPN-ssh unencrypted
60MB/s standard ssh
The tradeoff mbuffer is a little more complicated to script; rsh is, well,
you know; and hpn-ssh requires
>
> I've heard you could, but I've never done it. Sorry I'm not much help,
> except as a cheer leader. You can do it! I think you can! Don't give
> up! heheheheh
> Please post back whatever you find, or if you have to figure it out for
> yourself, then blog about it and post that.
Aha! Gotc
Post in the list.
> -Original Message-
> From: Fred Liu
> Sent: 星期五, 十二月 14, 2012 23:41
> To: 'real-men-dont-cl...@gmx.net'
> Subject: RE: [zfs-discuss] any more efficient way to transfer snapshot
> between two hosts than ssh tunnel?
>
>
>
> >
> > Hi Fred,
> >
> > I played with zfs send
>
> We have found mbuffer to be the fastest solution. Our rates for large
> transfers on 10GbE are:
>
> 280MB/smbuffer
> 220MB/srsh
> 180MB/sHPN-ssh unencrypted
> 60MB/s standard ssh
>
> The tradeoff mbuffer is a little more complicated to script; rsh is,
> well, you know;
In my own experiments with my own equivalent of mbuffer, it's well worth
giving the receiving side a buffer which is sized to hold the amount of
data in a transaction commit, which allows ZFS to be banging out one tx
group to disk, whilst the network is bringing the next one across for
it. This
On Fri, Dec 14 at 9:29, Fred Liu wrote:
We have found mbuffer to be the fastest solution. Our rates for large
transfers on 10GbE are:
280MB/smbuffer
220MB/srsh
180MB/sHPN-ssh unencrypted
60MB/s standard ssh
The tradeoff mbuffer is a little more complicated to script; rs
On 12/14/12 10:07 AM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
wrote:
Is that right? You can't use zfs send | zfs receive to send from a newer
version and receive on an older version?
No. You can, with recv, override any property in the sending stream that can be
set from t
I have removed all L2arc devices as a precaution. Has anyone seen this
error with no L2arc device configured?
On Thu, Dec 13, 2012 at 9:03 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Wed, 12 Dec 2012, Jamie Krier wrote:
>
>>
>>
>> I am thinking about switching to an Illumos
14 matches
Mail list logo
