If it's just performance you're after for small
writes, I wonder if you've considered putting the ZIL
on an NVRAM card? It looks like this can give
something like a 20x performance increase in some
situations:
http://blogs.sun.com/perrin/entry/slog_blog_or_bloggin
g_on
That's certainly
Joerg Schilling wrote:
Al Hopper [EMAIL PROTECTED] wrote:
I've personally (and professionally) been bitten by all 3 above
scenarios - more than once! IMHO, SATA point-to-point serial links
are far more reliable than anything I could build with SCSI
technology.
SCSI is (since SCSI-3)
I'm using the thumper as a secondary storage device and therefor am technically
only worried about capacity and performance. In regards to availability, if it
fails I should be okay as long as I don't also lose the primary storage during
the time it takes to recover the secondary [knock on
Aaah, that makes sense :)
If it's just performance you're after for small writes, I wonder if you've
considered putting the ZIL on an NVRAM card? It looks like this can give
something like a 20x performance increase in some situations:
Kam Lane wrote:
I'm getting ready to test a thumper (500gig drives/ 16GB) as a backup store
for small (avg 2kb) encrypted text files. I'm considering a zpool of 7 x 5+1
raidz1 vdevs to maximize space and provide some level of redundancy carved
into about 10 zfs filesystems. Since the files
On Nov 29, 2007 11:41 AM, Richard Elling [EMAIL PROTECTED] wrote:
It depends on the read pattern. If you will be reading these small
files randomly, then there may be a justification to tune recordsize.
In general, backup/restore workloads are not random reads, so you
may be ok with the
Mike Gerdts wrote:
On Nov 29, 2007 11:41 AM, Richard Elling [EMAIL PROTECTED] wrote:
It depends on the read pattern. If you will be reading these small
files randomly, then there may be a justification to tune recordsize.
In general, backup/restore workloads are not random reads, so you
No need to tune recordsize when the filesizes are small. Each file is
stored as a single record.
-r
Le 29 nov. 07 à 08:20, Kam Lane a écrit :
I'm getting ready to test a thumper (500gig drives/ 16GB) as a
backup store for small (avg 2kb) encrypted text files. I'm
considering a zpool
Might be off-topic slightly, but why not raid-z2? We're looking at a thumper
ourselves and I'd be nervous of data loss with single parity raid (I've had
enough close calls with SCSI drives, let alone SATA).
This message posted from opensolaris.org
On Thu, 29 Nov 2007, Ross wrote:
reformatted ...
Might be off-topic slightly, but why not raid-z2? We're looking at
a thumper ourselves and I'd be nervous of data loss with single
parity raid (I've had enough close calls with SCSI drives, let alone
SATA).
What do you mean by let
Al Hopper wrote:
On Thu, 29 Nov 2007, Ross wrote:
reformatted ...
Might be off-topic slightly, but why not raid-z2? We're looking at
a thumper ourselves and I'd be nervous of data loss with single
parity raid (I've had enough close calls with SCSI drives, let alone
SATA).
Thanks everyone. Basically I'll be generating a list of files to grab and doing
a wget to pull individual files from an apache web server and then placing them
in their respective nested directory location. When it comes time for a
restore, I generate another list of files scattered throughout
I'm getting ready to test a thumper (500gig drives/ 16GB) as a backup store for
small (avg 2kb) encrypted text files. I'm considering a zpool of 7 x 5+1 raidz1
vdevs to maximize space and provide some level of redundancy carved into about
10 zfs filesystems. Since the files are encrypted,
Point of clarification: I meant recordsize. I'm guessing {from what I've read}
that the blocksize is auto-tuned.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
14 matches
Mail list logo
