On 6/5/14, 5:06 AM, Dan Swartzendruber wrote:
Second this. The DC S3700 are very good.
Okay, so far so good. 100MB s3700 came today. threw it in the tank pool
as log device, and set sync=standard. Re-ran crystaldiskmark and get
93MB/sec writes. Given that reads are running 106MB/sec, I
I scrub weekly already :)
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
5 июня 2014 г. 11:21:24 CEST, Saso Kiselkov skiselkov...@gmail.com пишет:
On 6/5/14, 5:06 AM, Dan Swartzendruber wrote:
Second this. The DC S3700 are very good.
Okay, so far so good. 100MB s3700 came today. threw it in the tank
pool
as log device, and set sync=standard. Re-ran
Second this. The DC S3700 are very good.
Okay, so far so good. 100MB s3700 came today. threw it in the tank pool
as log device, and set sync=standard. Re-ran crystaldiskmark and get
93MB/sec writes. Given that reads are running 106MB/sec, I think it's
time to call this a win... Thanks all
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 5/29/2014 11:19 AM, Dan Swartzendruber wrote:
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
On May 29, 2014, at 11:25 AM, Doug Hughes d...@will.to wrote:
The higher price is the reason I tend to prefer the 320 series that come in
around $1/GB and have smaller sizes available. I use them for OS + slog.
What about the S3500? I've heard that's more the drop-in replacement for the
On 5/29/14, 5:48 PM, Dan McDonald wrote:
On May 29, 2014, at 11:25 AM, Doug Hughes d...@will.to wrote:
The higher price is the reason I tend to prefer the 320 series that come in
around $1/GB and have smaller sizes available. I use them for OS + slog.
What about the S3500? I've heard
On May 29, 2014, at 11:58 AM, Saso Kiselkov skiselkov...@gmail.com wrote:
On 5/29/14, 5:48 PM, Dan McDonald wrote:
On May 29, 2014, at 11:25 AM, Doug Hughes d...@will.to wrote:
The higher price is the reason I tend to prefer the 320 series that come in
around $1/GB and have smaller
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
] Status of TRIM support?
Nate Smith wrote:
Third on S3700. They're the best mix of price/reliability.
Has anyone used the Seagate 600 Pro series? ST240FP0021?
Only the non-pro version. I ran a quick comparison with S3700s and
ended up using them as cache devices.
--
Ian
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
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 on zfs zfs-create.blogspot.com. Here's why I think
On May 27, 2014, at 9:11 PM, Dan Swartzendruber dswa...@druber.com wrote:
SNIP!
Does over-provisioning help?
It might.
I'm no ZFS performance expert. You're better off asking that question on the
Illumos ZFS list.
I've mentioned before here that Nexenta had a prototype of TRIM/UNMAP use
cked.) If you switch manually from host A to B, all is well, since
Zfs does not depend on sync writes ('zil') for pool integrity. It
does depend on cache flush across all disks for pool integrity. The
harm from sync=disabled is that when the system comes back up, the
data may not be
27 matches
Mail list logo
