26 мая 2014 г. 9:36:02 CEST, Filip Marvan filip.mar...@aira.cz пишет:
Hello,
just for information, after two weeks, numbers of ARC assesses came
back to
high numbers as before deletion of data (you can see that in
screenshot).
And I try to delete the same amount of data on different storage
28 мая 2014 г. 3:11:07 CEST, Dan Swartzendruber dswa...@druber.com пишет:
So I've been running with sync=disabled on my vsphere NFS datastore.
I've
been willing to do so because I have a big-ass UPS, and do hourly
backups.
But, I'm thinking of going to an active/passive connection to my JBOD,
On 5/28/14, 3:11 AM, Dan Swartzendruber wrote:
So I've been running with sync=disabled on my vsphere NFS datastore. I've
been willing to do so because I have a big-ass UPS, and do hourly backups.
But, I'm thinking of going to an active/passive connection to my JBOD,
using Saso's blog post
(merging comments to Saso and Jim)
I don't think I mentioned my environment - if not, my apologies. This is
a SOHO/Lab setup, so things like zeusram are non-starters. The basic
network infrastructure is gigabit, so iSCSI ZIL would suck badly, I
suspect. As far as over-provisioning the 840PRO,
The 840 Pro doesn't have a super cap, but it does properly honor cache
flushes which ZFS will do on a log device. This drastically reduces it's
write performance and makes it a poor choice for a log device.
Intel has several SATA SSDs with proper super-cap protected caches that
make good log
On 5/28/14, 3:51 PM, Dan Swartzendruber wrote:
(merging comments to Saso and Jim)
I don't think I mentioned my environment - if not, my apologies. This is
a SOHO/Lab setup, so things like zeusram are non-starters. The basic
network infrastructure is gigabit, so iSCSI ZIL would suck badly,
On 5/28/14, 4:08 PM, Schweiss, Chip wrote:
Intel has several SATA SSDs with proper super-cap protected caches that
make good log devices.
I'd recommend looking at a Intel DC S3700. The 200 GB or 400 GB
varieties promise ~3 4k random write IOPS and actually seem to deliver:
On 5/28/2014 10:34 AM, Saso Kiselkov wrote:
On 5/28/14, 4:08 PM, Schweiss, Chip wrote:
Intel has several SATA SSDs with proper super-cap protected caches that
make good log devices.
I'd recommend looking at a Intel DC S3700. The 200 GB or 400 GB
varieties promise ~3 4k random write IOPS
On Wed, May 28, 2014 at 9:46 AM, Doug Hughes d...@will.to wrote:
Second this. The DC S3700 are very good.
But, I tend to use the Intel 320 which are often available on amazon for
just over $1/GB up to 600GB. They don't have as good of specs as the DC3700
(which are newer), but they do have
I never tried them, but I know that the M500 and the M550 also have the
capacitor. Less write cycles, but probably enough for SOHO.
Anandtech tested them both.
Olaf
Il giorno 28/mag/2014, alle ore 19:44, Nate Smith nsm...@careyweb.com ha
scritto:
Third on S3700. They're the best mix of
It looks to me like Sa¨o's design is active/standby failover. Zpool
import on the standby should obtain a clean transaction group as long
as the originally active system is still not using the pool. The
result would be similar to the power fail situation.
As long as the right fencing is
On Wed, May 28, 2014 at 1:55 PM, Dan Swartzendruber dswa...@druber.comwrote:
It looks to me like Sa¨o's design is active/standby failover. Zpool
import on the standby should obtain a clean transaction group as long
as the originally active system is still not using the pool. The
result
Assuming you have real SAS devices in the pool, not SATA with interposers,
you can use SCSI reservations. This can block the other host from
accessing a pool you are about to take over.
sg3_utils has utilities for managing SCSI reservations.
The data pool is in fact all SAS. 8 1TB
Saso Kiselkov wrote:
Hi Dan,
First off, the Samsung 840 Pro apparently doesn't have power loss
protection, so DON'T use it for slog (ZIL). Use some enterprise-class
SSD that has proper protection of its DRAM contents. Even better, if you
have the cash to spend, get a ZeusRAM - these are true
The nice thing about the pros is they do have power loss protection.
_
From: Ian Collins [mailto:i...@ianshome.com]
To: Nate Smith [mailto:nsm...@careyweb.com]
Cc: 'omnios-discuss' [mailto:omnios-discuss@lists.omniti.com]
Sent: Wed, 28 May 2014 18:51:18 -0500
Subject: Re:
On May 28, 2014, at 7:08 AM, Schweiss, Chip c...@innovates.com wrote:
The 840 Pro doesn't have a super cap, but it does properly honor cache
flushes which ZFS will do on a log device. This drastically reduces it's
write performance and makes it a poor choice for a log device.
This is a
Trying to sort this out on a new build running the latest OmniOS release, the
adapter is on the Illumos HCL and works like a charm when the system is booted
into the live CentOS environment.
Tried the X540 based Supermicro add-on card for comparison and that initialized
just fine.
Any
On May 28, 2014, at 8:06 PM, Andrew Brant andr...@icc-usa.com wrote:
Trying to sort this out on a new build running the latest OmniOS release, the
adapter is on the Illumos HCL and works like a charm when the system is
booted into the live CentOS environment.
Tried the X540 based
H. My fault. Wrong code.
Failed to initialize adapter
That's what you said.
THIS code:
/*
* Initialize chipset hardware
*/
if (ixgbe_init(ixgbe) != IXGBE_SUCCESS) {
ixgbe_error(ixgbe, Failed to initialize adapter);
goto
19 matches
Mail list logo
