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,
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
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
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 start on my
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 occurred
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
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
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 Robert
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 filesystem 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
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.
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
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 and the GPL
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
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 frame types,
: 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 as
19 matches
Mail list logo
