On 06/01/2011 00:14, Edward Ned Harvey wrote:
solaris engineers don't use? Non-sun hardware. Pretty safe bet you won't
find any Dell servers in the server room where solaris developers do their
thing.
You would lose that bet, not only would you find Dell you would many
other "big names" as w
I've deployed large SAN's on both SuperMicro 825/826/846 and Dell
R610/R710's and I've not found any issues so far. I always make a point of
installing Intel chipset NIC's on the DELL's and disabling the Broadcom ones
but other than that it's always been plain sailing - hardware-wise anyway.
I've
> From: Richard Elling [mailto:richard.ell...@nexenta.com]
>
> If I understand correctly, you want Dell, HP, and IBM to run OSes other
>
> I agree, but neither Dell, HP, nor IBM develop Windows...
>
> I'm not sure of the current state, but many of the Solaris engineers
develop
> on laptops and S
This is a silly argument, but...
Haven't seen any underdog proven solid enough for me to deploy in
enterprise yet.
I haven't seen any "over"dog proven solid enough for me to be able to rely
on either. Certainly not Solaris. Don't get me wrong, I like(d) Solaris.
But every so often you'd fi
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
>
> On Wed, 5 Jan 2011, Edward Ned Harvey wrote:
> > with regards to ZFS and all the other projects relevant to solaris.)
> >
> > I know in the case of SGE/OGE, it's officially closed source now. As of
Dec
> > 31st, sunsource is being
> From: Khushil Dep [mailto:khushil@gmail.com]
>
> I've deployed large SAN's on both SuperMicro 825/826/846 and Dell
> R610/R710's and I've not found any issues so far. I always make a point of
> installing Intel chipset NIC's on the DELL's and disabling the Broadcom ones
> but other than that
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
> >
> > But that's precisely why it's an impossible situation. In order for the
> > client to see a checksum error, it must have read some corrupt data from
> the
> > pool storage, but the server will never allow that to happen. So the
Two fold really - firstly I remember the headaches I used to have
configuring Broadcom cards properly under Debain/Ubuntu but the sweetness
that was using an Intel NIC. Bottom line for me was that I know Intel
drivers have been around longer than Broadcom drivers and thus it would make
sense to ens
For anyone that is interested, here's a progress report.
I created a new pool with only one mirror vdev of 2 disks, namely with the new
SAMSUNG HD204UI. These drives, along with the older HD203WI, use Advanced
Format Technology (e.g. 4K sectors). Only these drives had hard errors in my
pool, as
On Jan 5, 2011, at 7:44 AM, Edward Ned Harvey wrote:
>> From: Khushil Dep [mailto:khushil@gmail.com]
>>
>> We do have a major commercial interest - Nexenta. It's been quiet but I do
>> look forward to seeing something come out of that stable this year? :-)
>
> I'll agree to call Nexenta "a m
On Jan 5, 2011, at 4:14 PM, Edward Ned Harvey wrote:
>> From: Richard Elling [mailto:richard.ell...@nexenta.com]
>>
>>> I'll agree to call Nexenta "a major commerical interest," in regards to
>> contribution to the open source ZFS tree, if they become an officially
>> supported OS on Dell, HP, an
On Thu, Jan 6, 2011 at 5:33 AM, Edward Ned Harvey
wrote:
> But the conclusion remains the same: Redundancy is not needed at the
> client, because any data corruption the client could possibly see from the
> server would be transient and self-correcting.
Weren't you just chastising someone else f
On Thu, December 23, 2010 22:45, Edward Ned Harvey wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Bill Werner
>>
>> on a single 60GB SSD drive, use FDISK to create 3 physical partitions, a
> 20GB
>> for boot, a 30GB for L2ARC and a
Folks,
I have been told that the checksum value returned by Sha256 is almost
guaranteed to be unique. In fact, if Sha256 fails in some case, we have a
bigger problem such as memory corruption, etc. Essentially, adding verification
to sha256 is an overkill.
Perhaps (Sha256+NoVerification) would
On 5 January 2011 13:26, Edward Ned Harvey
wrote:
> One comment about etiquette though:
>
I'll certainly bear your comments in mind in future, however I'm not
sure what happened to the subject, as I used the interface at
http://opensolaris.org/jive/. I thought that would keep the subject
the sam
On 6 January 2011 20:02, Chris Murray wrote:
> On 5 January 2011 13:26, Edward Ned Harvey
> wrote:
>> One comment about etiquette though:
>>
>
>
> I'll certainly bear your comments in mind in future, however I'm not
> sure what happened to the subject, as I used the interface at
> http://opensola
On Thu, January 6, 2011 14:44, Peter Taps wrote:
> I have been told that the checksum value returned by Sha256 is almost
> guaranteed to be unique. In fact, if Sha256 fails in some case, we have a
> bigger problem such as memory corruption, etc. Essentially, adding
> verification to sha256 is an ov
On 01/ 6/11 07:44 PM, Peter Taps wrote:
Folks,
I have been told that the checksum value returned by Sha256 is almost
guaranteed to be unique. In fact, if Sha256 fails in some case, we have a
bigger problem such as memory corruption, etc. Essentially, adding verification
to sha256 is an overk
On Jan 6, 2011, at 11:44 AM, Peter Taps wrote:
> Folks,
>
> I have been told that the checksum value returned by Sha256 is almost
> guaranteed to be unique. In fact, if Sha256 fails in some case, we have a
> bigger problem such as memory corruption, etc. Essentially, adding
> verification to s
On Thu, Jan 06, 2011 at 11:44:31AM -0800, Peter Taps wrote:
> I have been told that the checksum value returned by Sha256 is almost
> guaranteed to be unique.
All hash functions are guaranteed to have collisions [for inputs larger
than their output anyways].
> In fact, if
On Jan 6, 2011, at 15:57, Nicolas Williams wrote:
> Fletcher is faster than SHA-256, so I think that must be what you're
> asking about: "can Fletcher+Verification be faster than
> Sha256+NoVerification?" Or do you have some other goal?
Would running on recent T-series servers, which have have o
On Thu, Jan 06, 2011 at 06:07:47PM -0500, David Magda wrote:
> On Jan 6, 2011, at 15:57, Nicolas Williams wrote:
>
> > Fletcher is faster than SHA-256, so I think that must be what you're
> > asking about: "can Fletcher+Verification be faster than
> > Sha256+NoVerification?" Or do you have some o
> From: Brandon High [mailto:bh...@freaks.com]
>
> On Thu, Jan 6, 2011 at 5:33 AM, Edward Ned Harvey
> wrote:
> > But the conclusion remains the same: Redundancy is not needed at the
> > client, because any data corruption the client could possibly see from
the
> > server would be transient and
> From: Edward Ned Harvey
>
> To: "'Khushil Dep'"
> Cc: Richard Elling ,
> zfs-discuss@opensolaris.org
> Subject: Re: [zfs-discuss] A few questions
> Message-ID: <000201cbada5$a3678270$ea3687...@nedharvey.com>
> Content-Type: text/plain; charset="utf-8"
>
> > From: Khushil Dep [mailt
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Peter Taps
>
> Perhaps (Sha256+NoVerification) would work 99.99% of the time. But
Append 50 more 9's on there.
99.%
See below.
>
Ed, with all due respect to your math,
I've seen rsync bomb due to an SHA256 collision, so I know it can and does
happen.
I respect my data, so even with checksumming and comparing the block size, I'll
still do a comparison check if those two match. You will end up with silent
data corruption
At the end of the day this issue essentially is about mathematical
improbability versus certainty?
To be quite honest, I too am skeptical about about using de-dupe just based on
SHA256. In prior posts it was asked that the potential adopter of the
technology provide the mathematical reason to
Hi ZFS Discuss,
I have a 8x 1TB RAIDZ running on Samsung 1TB 5400rpm drives with 512b sectors.
I will be replacing all of these with 8x Western Digital 2TB drives
with support for 4K sectors. The replacement plan will be to swap out
each of the 8 drives until all are replaced and the new size (~
zfs replace will copy across on to the disk with the same old ashift=9,
whereas you want ashift=12 for 4KB drives. (size = 2^ashift)
You'd need to make a new pool (or add a vdev to an existing pool) with the
modified tools in order to get proper performance out of 4KB drives.
On 7 January 2011 17
29 matches
Mail list logo
