Thanks for all your help, changing the mode from RAID to JBOD did the
trick. I was hoping to have a RAID 1+0 for the OS, but I guess with Areca
is all or nothing.
Cheers,
Gregory
On Fri, 8 May 2009, James C. McPherson wrote:
On Thu, 07 May 2009 16:59:01 -0400
milosz wrote:
with pass-thr
On Thu, 07 May 2009 16:59:01 -0400
milosz wrote:
> with pass-through disks on areca controllers you have to set the lun id (i
> believe) using the volume command. when you issue a volume info your disk
> id's should look like this (if you want solaris to see the disks):
>
> 0/1/0
> 0/2/0
> 0/3/
with pass-through disks on areca controllers you have to set the lun id (i
believe) using the volume command. when you issue a volume info your disk
id's should look like this (if you want solaris to see the disks):
0/1/0
0/2/0
0/3/0
0/4/0
etc.
the middle part there (again, i think that's suppos
On Thu, 7 May 2009, Mike Gerdts wrote:
Perhaps you have change the configuration of the array since the last
reconfiguration boot. If you run "devfsadm" then run format, does it
see more disks?
Another thing to check is to see if the controller has a "jbod" mode as
opposed to passthrough.
On Thu, May 7, 2009 at 3:29 PM, Gregory Skelton
wrote:
> Hi Everyone,
>
> I want to start out by saying ZFS has been a life saver to me, and the
> scientific collaboration I work for. I can't imagine working with the TB's
> of data that we do, without the snapshots or the ease of moving the data
>
> "re" == Richard Elling writes:
re> PSARC 2007/567
oh, failmode? We were not talking about panics. We're talking about
corrupted pools. Many of the systems in bugs related to this PSARC
are not even using a SAN and are not reporting problems simliar to the
one I described.
Remember
Hi Everyone,
I want to start out by saying ZFS has been a life saver to me, and the
scientific collaboration I work for. I can't imagine working with the TB's of
data that we do, without the snapshots or the ease of moving the data from one
pool to another.
Right now I'm trying to setup a wh
On Thu, 7 May 2009, Moore, Joe wrote:
Carson Gaspar wrote:
Not true. The script is simply not intelligent enough. There are really
3 broad kinds of RAM usage:
A) Unused
B) Unfreeable by the kernel (normal process memory)
C) Freeable by the kernel (buffer cache, ARC, etc.)
Monitoring usually s
Carson Gaspar wrote:
> Not true. The script is simply not intelligent enough. There are really
> 3 broad kinds of RAM usage:
>
> A) Unused
> B) Unfreeable by the kernel (normal process memory)
> C) Freeable by the kernel (buffer cache, ARC, etc.)
>
> Monitoring usually should focus on keeping (A+
>I'll call bull* on that. Microsoft has an admirably simple installation
>and 88% of the market. Apple has another admirably simple installation
>and 10% of the market. Solaris has less than 1% of the market and has
>had a very complex installation process. You can't win that battle by
>increa
Hi.. I'm not exactly familiar with the ARC/sponsor process, but thought
I'd toss this out since Vladimir 'phcoder' Serbinenko mentioned the
benefits of his port for grub2.
I think by doing some sort of formal process we'll actually get feedback
about the best way to move forward. There are
Fajar A. Nugraha wrote:
On Wed, May 6, 2009 at 10:17 PM, Richard Elling
wrote:
Fajar A. Nugraha wrote:
IMHO it's probably best to set a limit on ARC size and treat it like
any other memory used by applications.
There are a few cases where this makes sense, but not many.
Carson Gaspar wrote:
Richard Elling wrote:
Miles Nordin wrote:
AIUI the later BE's are clones of the first, and not all blocks
will be rewritten, so it's still an issue. no?
In practice, yes, they are clones. But whether it is an issue
depends on what the "issue" is. As I see it, the iss
On Wed, May 6, 2009 at 10:17 PM, Richard Elling
wrote:
> Fajar A. Nugraha wrote:
>> IMHO it's probably best to set a limit on ARC size and treat it like
>> any other memory used by applications.
>>
>
> There are a few cases where this makes sense, but not many. The ARC
> will shrink, as needed.
Miles Nordin wrote:
"re" == Richard Elling writes:
re> We forget because it is no longer a problem ;-)
bug number?
PSARC 2007/567
re> I think it is disingenuous to compare an enterprise-class RAID
re> array with the random collection of hardware on which Solari
Richard Elling wrote:
Miles Nordin wrote:
AIUI the later BE's are clones of the first, and not all blocks
will be rewritten, so it's still an issue. no?
In practice, yes, they are clones. But whether it is an issue
depends on what the "issue" is. As I see it, the issue is that
someone wants
Bob Friesenhahn wrote:
It seems like this Nagios script is not very useful since the notion of
"free memory" has become antiquated.
Not true. The script is simply not intelligent enough. There are really
3 broad kinds of RAM usage:
A) Unused
B) Unfreeable by the kernel (normal process memor
On Thu, 7 May 2009, Robert Milkowski wrote:
On Wed, 6 May 2009, Miles Nordin wrote:
"re" == Richard Elling writes:
re> We forget because it is no longer a problem ;-)
bug number?
re> I think it is disingenuous to compare an enterprise-class RAID
re> array with the random coll
On Wed, 6 May 2009, Miles Nordin wrote:
"re" == Richard Elling writes:
re> We forget because it is no longer a problem ;-)
bug number?
re> I think it is disingenuous to compare an enterprise-class RAID
re> array with the random collection of hardware on which Solaris
re> runs.
19 matches
Mail list logo
