> 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 cer
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:
http://blogs.sun.com/perrin/entry/slog_blog_or_blogging_on
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 wood]
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 (s
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) a layered protocol and
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 t
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
>> S
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)
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
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
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
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,
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
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 fil
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
http://mail.opensolaris.org/mailman/lis
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, compre
16 matches
Mail list logo
