Thanks for the detailed reply, Robert. A significant part of it seems to be
suggesting that high-end array hardware from multiple vendors may be
*introducing* error sources that studies like CERN's (and Google's, and CMU's)
never encountered (based, as they were, on low-end hardware).
If so, t
2007/11/9, Anton B. Rang <[EMAIL PROTECTED]>:
> The comment in the header file where this error is defined says:
>
> /* volume is too large for 32-bit system */
>
> So it does look like it's a 32-bit CPU issue. Odd, since file systems don't
> normally have any sort of dependence on the CPU type
*push*
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Are all 24 disks in one big raidz raid set with no spares assigned to
the pool? If so then maybe the host is having trouble operating on
parity over that many drives when the "experienced an unrecoverable
error" errors occur. From what I've read it might be better to create
the pool with 3 raidz se
Let's stop feeding the troll...
-Original Message-
From: [EMAIL PROTECTED] on behalf of Richard Elling
Sent: Thu 11/8/2007 11:45 PM
To: can you guess?
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Yager on ZFS
can you guess? wrote:
> CERN was using relatively cheap disks an
> bull*
> -- richard
Hmmm.
Was that "bull*" as in
"Numbers? We don't need no stinking numbers! We're so cool that we work for a
guy who thinks he's Steve Jobs!"
or
"Silly engineer! Can't you see that I've got my rakish Marketing hat on?
Backwards!"
or
"I jes got back from an early sta
can you guess? wrote:
> CERN was using relatively cheap disks and found that they were more than
> adequate (at least for any normal consumer use) without that additional level
> of protection: the incidence of errors, even including the firmware errors
> which presumably would not have occurr
Most video formats are designed to handle errors--they'll drop a frame
or two, but they'll resync quickly. So, depending on the size of the
error, there may be a visible glitch, but it'll keep working.
Interestingly enough, this applies to a lot of MPEG-derived formats as
well, like MP3. I had a
Hello can,
Friday, November 9, 2007, 8:16:12 AM, you wrote:
cyg> If so, then at least a major part of your improved experience is
cyg> not due to using ZFS per se but to getting rid of the high-end
cyg> equipment and using more reliable commodity parts: a remarkable
cyg> thought - I wonder if an
> A quick Google of ext3 fsck did not yield obvious examples of why people
> needed to run fsck on ext3, though it did remind me that by default ext3 runs
> fsck just for the hell of it every N (20?) mounts - could that have been part
> of what you were seeing?
I'm not sure if that's what Robe
Hi Guys,
Someone asked me how to count the number of inodes/objects in a ZFS
filesystem and I wasn't exactly sure. "zdb -dv " seems
like a likely candidate but I wanted to find out for sure. As to why
you'd want to know this, I don't know their reasoning but I assume it
has to do with the maximum
On Fri, Nov 09, 2007 at 12:11:48 -0700, Jason J. W. Williams wrote:
: I'm somewhat surprised its being used as
: a counterexample of journaling filesystems being no less reliable than
: ZFS. XFS or ReiserFS are both better examples than ext3.
I tend to use XFS on my Linux boxes because of it.
Rei
Dickon Hood <[EMAIL PROTECTED]> wrote:
> ZFS would be lovely. Pity about the licence issues.
There is no license issue: the CDDL allows a combination
with any other license and the GPL does not forbid a GPL
project to use code under other licenses in case that the
non-GPL code does not become a
On Fri, Nov 09, 2007 at 21:34:35 +0100, Joerg Schilling wrote:
: Dickon Hood <[EMAIL PROTECTED]> wrote:
: > ZFS would be lovely. Pity about the licence issues.
: There is no license issue: the CDDL allows a combination
: with any other license and the GPL does not forbid a GPL
: project to use c
Dickon Hood <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 09, 2007 at 21:34:35 +0100, Joerg Schilling wrote:
> : Dickon Hood <[EMAIL PROTECTED]> wrote:
>
> : > ZFS would be lovely. Pity about the licence issues.
>
> : There is no license issue: the CDDL allows a combination
> : with any other license
You can just do something like this:
# zfs list tank/home/billm
NAMEUSED AVAIL REFER MOUNTPOINT
tank/home/billm83.9G 5.56T 74.1G /export/home/billm
# zdb tank/home/billm
Dataset tank/home/billm [ZPL], ID 83, cr_txg 541, 74.1G, 111066 objects
L
> Most video formats are designed to handle
> errors--they'll drop a frame
> or two, but they'll resync quickly. So, depending on
> the size of the
> error, there may be a visible glitch, but it'll keep
> working.
Actually, Let's take MPEG as an example. There are two basic frame types,
anchor
> > Most video formats are designed to handle
> > errors--they'll drop a frame
> > or two, but they'll resync quickly. So, depending
> on
> > the size of the
> > error, there may be a visible glitch, but it'll
> keep
> > working.
>
> Actually, Let's take MPEG as an example. There are
> two basic
> : In case of a filesystem, I do not see why the
> filesystem could
> : be a derived work from e.g. Linux.
>
> Indeed not, however AIUI the FSF do.
My impression is that GPFS on Linux was (and may still be) provided as a binary
proprietary loadable kernel module, plus some GPL glue. Not by any
can you guess? wrote:
...
> Ah - thanks to both of you. My own knowledge of video format internals
> is so limited that I assumed most people here would be at least equally
> familiar with the notion that a flipped bit or two in a video would
> hardly qualify as any kind of disaster (or often even
20 matches
Mail list logo
