Le 4 août 09 à 20:25, Prabahar Jeyaram a écrit :
On Tue, Aug 04, 2009 at 01:01:40PM -0500, Bob Friesenhahn wrote:
On Tue, 4 Aug 2009, Prabahar Jeyaram wrote:
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris
On Fri, Oct 30, 2009 at 09:48:39AM +0100, Ga?tan Lehmann wrote:
Le 4 ao?t 09 ? 20:25, Prabahar Jeyaram a ?crit :
On Tue, Aug 04, 2009 at 01:01:40PM -0500, Bob Friesenhahn wrote:
On Tue, 4 Aug 2009, Prabahar Jeyaram wrote:
You seem to be hitting :
On Fri, 30 Oct 2009, Gaëtan Lehmann wrote:
Yes. It is planned for S10U9.
In the mean time, is there a patch available for Solaris 10?
I can't find it on sunsolve.
Notice that the fix for this requires adding a new kernel scheduling
class with default lower priority than user processes,
Prabahar Jeyaram wrote:
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris build 115 and later not for Solaris 10 yet.
Have you got more information on how was it fixed?
--
Robert Milkowski
Are there any improvements in the Solaris 10 pipeline for how
compression is implemented?
I changed my USB-based backup pool to use gzip compression (with
default level 6) rather than the lzjb compression which was used
before. When lzjb compression was used, it would case the X11 session
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris build 115 and later not for Solaris 10 yet.
--
Prabahar.
On Tue, Aug 04, 2009 at 10:08:37AM -0500, Bob Friesenhahn wrote:
Are there any improvements in the Solaris
On Tue, 4 Aug 2009, Prabahar Jeyaram wrote:
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris build 115 and later not for Solaris 10 yet.
It is interesting that this is a simple thread priority issue. The
system
Hi Bob,
Bob Friesenhahn wrote:
On Tue, 4 Aug 2009, Prabahar Jeyaram wrote:
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris build 115 and later not for
Solaris 10 yet.
It is interesting that this is a simple
On Tue, Aug 04, 2009 at 01:01:40PM -0500, Bob Friesenhahn wrote:
On Tue, 4 Aug 2009, Prabahar Jeyaram wrote:
You seem to be hitting :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537
The fix is available in OpenSolaris build 115 and later not for Solaris 10
yet.
It is
Hello Gino,
Monday, August 13, 2007, 8:51:18 AM, you wrote:
G Hello Robert,
G now we are using snv60 and snv67 and moving many TB of data every
G day and no corruption problem any more.
Good, thanks for info.
G Unfortunately the following problems force us to stay with UFS for our
production
Hello Robert,
now we are using snv60 and snv67 and moving many TB of data every day and no
corruption problem any more.
Unfortunately the following problems force us to stay with UFS for our
production servers:
6417779 ZFS: I/O failure (write on ...)
6322646 ZFS should gracefully handle all
Hello Gino,
Wednesday, April 11, 2007, 10:43:17 AM, you wrote:
On Tue, Apr 10, 2007 at 09:43:39PM -0700, Anton B.
Rang wrote:
That's only one cause of panics.
At least two of gino's panics appear due to
corrupted space maps, for
instance. I think there may also still be a case
Hi All
I'd like to expose two points about ZFS that I think are a must before even
trying to use it in production:
1) ZFS must stop to force kernel panics!
As you know ZFS takes to a kernel panic when a corrupted zpool is found or if
it's unable to reach
a device and so on...
We need to have
On Tue, Apr 10, 2007 at 12:48:49AM -0700, Gino wrote:
Hi All
I'd like to expose two points about ZFS that I think are a must before even
trying to use it in production:
1) ZFS must stop to force kernel panics!
As you know ZFS takes to a kernel panic when a corrupted zpool is found or
14 matches
Mail list logo
