On Mon, May 12, 2008 at 06:44:39PM +0200, Ralf Bertling wrote:
> ...you should be able to "simulate" a scrub on the latest data by
> using
> zfs send > /dev/null
> Since the primary purpose is to verify latent bugs and to have zfs
> auto-correct them, simply reading all data would be sufficient
Hi all,
until the scrub problem (http://bugs.opensolaris.org/view_bug.do?bug_id=6343667
) is fixed,you should be able to "simulate" a scrub on the latest data
by using
zfs send > /dev/null
Since the primary purpose is to verify latent bugs and to have zfs
auto-correct them, simply reading all
On Thu, 8 May 2008, Peter Tribble wrote:
> As a regular fileserver, yes - random reads of small files on raidz isn't
> too hot...
There that would pretty much be our usage scenario; home directories and
group project directories.
> I just disable NCQ and have done with it.
Doesn't that result i
On Wed, 7 May 2008, Bob Friesenhahn wrote:
> > It seems like kind of a waste to allocate 1TB to the operating system,
> > would there be any issue in taking a slice of those boot disks and
> > creating a zfs mirror with them to add to the pool?
>
> You don't want to go there. Keep in mind that th
On Wed, 7 May 2008, Richard Elling wrote:
> N.B. anyone can purchase a Production Subscription for OpenSolaris which
> would get both "support" and the in-kernel CIFS server.
> http://www.sun.com/service/opensolaris/index.jsp
Wow. That's new, and very intriguing. Any idea on the potential timelin
On 05/08/2008 11:29 AM, Luke Scharf wrote:
> Dave wrote:
>> On 05/08/2008 08:11 AM, Ross wrote:
>>
>>> It may be an obvious point, but are you aware that snapshots need to
>>> be stopped any time a disk fails? It's something to consider if
>>> you're planning frequent snapshots.
>>>
>>
>>
On May 8, 2008, at 12:31 PM, Carson Gaspar wrote:
> Luke Scharf wrote:
>> Dave wrote:
>>> On 05/08/2008 08:11 AM, Ross wrote:
>>>
It may be an obvious point, but are you aware that snapshots need
to be stopped any time a disk fails? It's something to consider
if you're plannin
[EMAIL PROTECTED] wrote on 05/08/2008 02:31:43 PM:
> Luke Scharf wrote:
> > Dave wrote:
> >> On 05/08/2008 08:11 AM, Ross wrote:
> >>
> >>> It may be an obvious point, but are you aware that snapshots
> need to be stopped any time a disk fails? It's something to
> consider if you're planning freq
Luke Scharf wrote:
> Dave wrote:
>> On 05/08/2008 08:11 AM, Ross wrote:
>>
>>> It may be an obvious point, but are you aware that snapshots need to be
>>> stopped any time a disk fails? It's something to consider if you're
>>> planning frequent snapshots.
>>>
>> I've never heard this bef
Bob Friesenhahn wrote:
> On Thu, 8 May 2008, Ross wrote:
>
>
>> protected even if a disk fails. I found this post quite an
>> interesting
>> read:http://blogs.sun.com/relling/entry/raid_recommendations_space_vs_mttdl
>>
>
> Richard's blog entry does not tell the whole story. ZFS does not
Dave wrote:
> On 05/08/2008 08:11 AM, Ross wrote:
>
>> It may be an obvious point, but are you aware that snapshots need to be
>> stopped any time a disk fails? It's something to consider if you're
>> planning frequent snapshots.
>>
>
> I've never heard this before. Why would snapshots n
On 05/08/2008 08:11 AM, Ross wrote:
> It may be an obvious point, but are you aware that snapshots need to be
> stopped any time a disk fails? It's something to consider if you're planning
> frequent snapshots.
I've never heard this before. Why would snapshots need to be stopped for
a disk fai
On Thu, 8 May 2008, Ross Smith wrote:
> True, but I'm seeing more and more articles pointing out that the
> risk of a secondary failure is increasing as disks grow in size, and
Quite true.
> While I'm not sure of the actual error rates (Western digital list
> their unrecoverable rates as < 1 i
On Thu, 8 May 2008, Ross wrote:
> protected even if a disk fails. I found this post quite an
> interesting
> read:http://blogs.sun.com/relling/entry/raid_recommendations_space_vs_mttdl
Richard's blog entry does not tell the whole story. ZFS does not
protect against memory corruption errors an
Mirrored drives should be fine. My understanding is that write performance
suffers slightly in a mirrored configuration, but random reads are much faster.
In your scenario I would expect mirroring to give far superior performance
than raid-z2.
We're looking to do something similar, but we're
On Wed, May 7, 2008 at 11:34 PM, Paul B. Henson <[EMAIL PROTECTED]> wrote:
>
> We have been evaluating ZFS as a potential solution for delivering
> enterprise file services for our campus.
...
> I was thinking about allocating 2 drives for the OS (SVM mirroring, pending
> ZFS boot support), two hot
On Wed, 7 May 2008, Paul B. Henson wrote:
>
> I was thinking about allocating 2 drives for the OS (SVM mirroring, pending
> ZFS boot support), two hot spares, and allocating the other 44 drives as
> mirror pairs into a single pool. While this will result in lower available
> space than raidz, my un
Paul B. Henson wrote:
> We have been evaluating ZFS as a potential solution for delivering
> enterprise file services for our campus. I've posted a couple of times with
> various questions, but to recap we want to provide file space to our
> approximately 22000 students and 2400 faculty/staff, as w
We have been evaluating ZFS as a potential solution for delivering
enterprise file services for our campus. I've posted a couple of times with
various questions, but to recap we want to provide file space to our
approximately 22000 students and 2400 faculty/staff, as well as group
project space fo
19 matches
Mail list logo
