On 27-Jan-07, at 10:15 PM, Anantha N. Srirama wrote:
... ZFS will not stop alpha particle induced memory corruption
after data has been received by server and verified to be correct.
Sadly I've been hit with that as well.
My brother points out that you can use a rad hardened CPU. ECC
[EMAIL PROTECTED] wrote:
On 27-Jan-07, at 10:15 PM, Anantha N. Srirama wrote:
... ZFS will not stop alpha particle induced memory corruption
after data has been received by server and verified to be correct.
Sadly I've been hit with that as well.
My brother points out that you
[EMAIL PROTECTED] wrote:
Alpha particles which hit CPUs must have their origin inside said CPU.
(Alpha particles do not penentrate skin, paper, let alone system cases
or CPU packagaging)
Gamma rays cannot be shielded in a senseful way.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg
Take note though, that giving zfs the entire disk gives a possible
performance win, as zfs will only enable the write cache for the disk
if it is given the entire disk.
really?
why this?
is this tuneable somehow/somewhere? can i enabyle writecache if only using a
dedicated partition ?
Take note though, that giving zfs the entire disk gives a possible
performance win, as zfs will only enable the write cache for the disk
if it is given the entire disk.
really?
why this?
In the old days, Sun never enabled the write cache on devices because
of reliability issues. (Sun SCSI
On 28-Jan-07, at 7:59 AM, [EMAIL PROTECTED] wrote:
On 27-Jan-07, at 10:15 PM, Anantha N. Srirama wrote:
... ZFS will not stop alpha particle induced memory corruption
after data has been received by server and verified to be correct.
Sadly I've been hit with that as well.
My brother
On 28-Jan-07, at 7:59 AM, [EMAIL PROTECTED] wrote:
On 27-Jan-07, at 10:15 PM, Anantha N. Srirama wrote:
... ZFS will not stop alpha particle induced memory corruption
after data has been received by server and verified to be correct.
Sadly I've been hit with that as well.
My brother
You're right that storage level snapshots are filesystem agnostic. I'm not sure
why you believe you won't be able to restore individual files by using a NetApp
snapshot? In the case of ZFS you'd take a periodic snapshot and use it to
restore files, in the case of NetApp you can do the same (of
Hello,
what is the status of the bug 6381203 fix in S10 u3 ?
(deadlock due to i/o while assigning (tc_lock held))
Was it integrated? Is there a patch?
Thanks,
[i]-- leon[/i]
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Fri, Jan 26, 2007 at 06:08:50PM -0800, Darren Dunham wrote:
What do you guys think about implementing 'zfs/zpool rewrite' command?
It'll read every block older than the date when the command was executed
and write it again (using standard ZFS COW mechanism, simlar to how
resilvering
Hi Leon,
This was fixed in March 2006, and is in S10_U2.
Neil.
Leon Koll wrote On 01/28/07 08:58,:
Hello,
what is the status of the bug 6381203 fix in S10 u3 ?
(deadlock due to i/o while assigning (tc_lock held))
Was it integrated? Is there a patch?
Thanks,
[i]-- leon[/i]
This message
Too bad...I was in the situation where every zpool ... command was stuck (as
well as df command) and my hope was - it's a known/fixed bug. I could not save
the core files, not sure I can reproduce the bug.
Thank you for quick reply,
[i]-- leon[/i]
This message posted from opensolaris.org
On Sat, Jan 27, 2007 at 04:15:30PM -0800, Anantha N. Srirama wrote:
I'm not sure what benefit you forsee by running a COW filesystem
(ZFS) on a COW array (NetApp).
The application requires a filesystem with POSIX semantics. My first
choice would be NFS from the Netapp, but this won't work in
On Sun, Jan 28, 2007 at 06:19:25AM -0800, Anantha N. Srirama wrote:
You're right that storage level snapshots are filesystem agnostic. I'm
not sure why you believe you won't be able to restore individual files
by using a NetApp snapshot? In the case of ZFS you'd take a periodic
snapshot and
On January 28, 2007 4:59:48 PM +0100 Pawel Jakub Dawidek [EMAIL PROTECTED]
wrote:
On Fri, Jan 26, 2007 at 06:08:50PM -0800, Darren Dunham wrote:
3. I created file system with huge amount of data, where most of the
data is read-only. I change my server from intel to sparc64 machine.
Adaptive
Anton B. Rang wrote:
How badly can you mess up a JBOD?
Two words: vibration, cooling.
Three more: power, signal quality.
I've seen even individual drive cases with bad enough signal quality to cause
bit errors.
Yep, if I crank up the amp to over 1kW, then on some frequencies, I see lots
Hello Richard,
Friday, January 26, 2007, 11:36:07 PM, you wrote:
RE We've been talking a lot recently about failure rates and types of
RE failures. As you may know, I do look at field data and generally don't
RE ask the group for more data. But this time, for various reasons (I
RE might have
Hello Jeff,
Saturday, January 27, 2007, 8:27:09 AM, you wrote:
JB You're all correct. File data is never byte-swapped. Most metadata
JB needs to be byte-swapped, but it's generally only 1-2% of your space.
JB So the overhead shouldn't be significant, even if you never rewrite.
I remember
Hello Anantha,
Friday, January 26, 2007, 5:06:46 PM, you wrote:
ANS All my feedback is based on Solaris 10 Update 2 (aka 06/06) and
ANS I've no comments on NFS. I strongly recommend that you use ZFS
ANS data redundancy (z1, z2, or mirror) and simply delegate the
ANS Engenio to stripe the data
Hello Francois,
Friday, January 26, 2007, 4:09:43 PM, you wrote:
FD On Fri, 2007-01-26 at 06:16 -0800, Jeffery Malloch wrote:
Hi Folks,
I am currently in the midst of setting up a completely new file server using
a pretty well loaded Sun T2000 (8x1GHz, 16GB RAM) connected to an Engenio
Agreed, I guess I didn't articulate my point/thought very well. The best config
is to present JBoDs and let ZFS provide the data protection. This has been a
very stimulating conversation thread; it is shedding new light into how to best
use ZFS.
This message posted from opensolaris.org
21 matches
Mail list logo
