On Thu, Mar 22 at 18:30, The Honorable Senator and Mrs. John Blutarsky wrote:
Ladies and Gentlemen,
I'm thinking about spending around 1,250 USD for a tower format (desk side)
server with RAM but without disks. I'd like to have 16G ECC RAM as a
minimum and ideally 2 or 3 times that amount and I'
On Thu, 22 Mar 2012, Jim Klimov wrote:
I think that a certain Bob F. would disagree, especially
when larger native sectors and ashist=12 come into play.
Namely, one scenario where this is important is automated
storage of thumbnails for websites, or some similar small
objects in vast amounts.
well
use component of x4170m2 as example you will be ok
intel cpu
lsi sas controller non raid
sas 72rpm hdd
my 2c
Sent from my iPad
On Mar 22, 2012, at 14:41, Bob Friesenhahn wrote:
> On Thu, 22 Mar 2012, The Honorable Senator and Mrs. John Blutarsky wrote:
>>
>> This will be a do-everything m
On Thu, 22 Mar 2012, The Honorable Senator and Mrs. John Blutarsky wrote:
This will be a do-everything machine. I will use it for development, hosting
various apps in zones (web, file server, mail server etc.) and running other
systems (like a Solaris 11 test system) in VirtualBox. Ultimately I
Ladies and Gentlemen,
I'm thinking about spending around 1,250 USD for a tower format (desk side)
server with RAM but without disks. I'd like to have 16G ECC RAM as a
minimum and ideally 2 or 3 times that amount and I'd like for the case to
have room for at least 6 drives, more would be better but
2012-03-22 20:52, Richard Elling wrote:
Yes, but it is a rare case for 512b sectors.
> It could be more common for 4KB sector disks when ashift=12.
...
Were there any research or tests regarding storage of many small
files (1-sector sized or close to that) on different vdev layouts?
It is not
On Mar 22, 2012, at 3:03 AM, Jim Klimov wrote:
> 2012-03-21 22:53, Richard Elling wrote:
> ...
>>> This is why a single
>>> vdev's random-read performance is equivalent to the random-read
>>> performance of
>>> a single drive.
>>
>> It is not as bad as that. The actual worst case number for a HDD
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of maillist reader
>
> I read though that ZFS does not have a "defragmentation" tool, is this
still the
> case?
True.
> It would seem with such a performance difference between
> "sequential r
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Paul Kraus
>
> Three are two different cases here... resilver to reconstruct
> data from a failed drive and a scrub to pro-actively find bad sectors.
>
> The best case situation for
2012-03-21 22:53, Richard Elling wrote:
...
This is why a single
vdev's random-read performance is equivalent to the random-read
performance of
a single drive.
It is not as bad as that. The actual worst case number for a HDD with
zfs_vdev_max_pending
of one is:
average IOPS * ((D+P) / D)
where,
10 matches
Mail list logo
