Uwe Dippel wrote:
If it was (successful), that would have been something. It wasn't.
It was; zfs successfully repaired the data, as is evidenced by the lack of
errors in the status output:
errors: No known data errors
'status' brought up the 'unrecoverable error', whatever number of
'scru
Hello Uwe,
Friday, April 17, 2009, 12:39:13 AM, you wrote:
UD> Drew Balfour wrote:
>>
>> Does anyone know why it's "applications" and not "data"?
>>
>> Perhaps something like:
>>
>> status: One or more devices has experienced an error. A successful
>> attempt to
>> correct the error was
Hello Blake,
Wednesday, April 15, 2009, 5:18:19 PM, you wrote:
B> You only need to decide what you want here. Yes, ext3 requires less
B> maintenance, because it can't tell you if a block becomes corrupt
B> (though fsck-in when that *does* happen can require hours, compared to
B> zfs replacing w
Hello Richard,
Thursday, April 16, 2009, 8:41:53 PM, you wrote:
RE> Tim wrote:
>> I can't say I've ever had to translate binary to recover an email from
>> the trash bin with Gmail... which is for "common users". Unless of
>> course you're suggesting "common users" will never want to recover a
Hello Jean-Noël,
Thursday, April 9, 2009, 3:39:50 PM, you wrote:
JNM> Hi François,
JNM> You should take care of the recordsize in your filesystems. This should
JNM> be tuned according to the size of the most accessed files.
I don't think this is necessary and it will rather do more harm than
go
Hello Uwe,
Thursday, April 16, 2009, 10:38:00 AM, you wrote:
UD> On Thu, Apr 16, 2009 at 1:05 AM, Fajar A. Nugraha wrote:
UD> [...]
UD> Thanks, Fajar, et al.
UD> What this thread actually shows, alas, is that ZFS is rocket science.
UD> In 2009, one would expect a file system to 'just work'. W
On Fri, 17 Apr 2009, Uwe Dippel wrote:
It seems most in here don't run production servers. A term like
'unrecoverable' sends me into a state of frenzy. It sounds like my systems
are dying any minute. From what I read, it is harmless. Some redundant
While your system is still running and user
Hello Harry,
Saturday, April 11, 2009, 5:05:47 PM, you wrote:
HP> So if I wanted to find a specific change in a file... that would be
HP> somewhere in the zfs snapthosts... say to retrieve a certain
HP> formulation in some kind of `rc' file that worked better than a later
HP> formulation. How wou
Drew Balfour wrote:
Does anyone know why it's "applications" and not "data"?
Perhaps something like:
status: One or more devices has experienced an error. A successful
attempt to
correct the error was made using a replicated copy of the data.
Data on the pool is unaffected.
On 16-Apr-09, at 5:27 PM, Florian Ermisch wrote:
Uwe Dippel schrieb:
Bob Friesenhahn wrote:
Since it was not reported that user data was impacted, it seems
likely that there was a read failure (or bad checksum) for ZFS
metadata which is redundantly stored.
(Maybe I am too much of a lingu
Now I wonder where that error came from. It was just a single
checksum error. It couldn't go away with an earlier scrub, and
seemingly left no traces of badness on the drive. Something serious?
At least it looks a tad contradictory: "Applications are
unaffected.", it is unrecoverable, and once
简朝阳 wrote:
> Hi,all
>
> I did some test about MySQL's Insert performance on ZFS, and met a big
> performance problem,*i'm not sure what's the point*.
>
> Environment
> 2 Intel X5560 (8 core), 12GB RAM, 7 slc SSD(Intel).
>
> A Java client run 8 threads concurrency insert into one Innodb table:
>
> *
Uwe Dippel schrieb:
Bob Friesenhahn wrote:
Since it was not reported that user data was impacted, it seems likely
that there was a read failure (or bad checksum) for ZFS metadata which
is redundantly stored.
(Maybe I am too much of a linguist to not stumble over the wording
here.) If it is
Tim wrote:
I can't say I've ever had to translate binary to recover an email from
the trash bin with Gmail... which is for "common users". Unless of
course you're suggesting "common users" will never want to recover a
file after zfs alerts them it's corrupted.
He's got a very valid point, an
The cool thing about the way Tim has built the service is that you can
edit the variable values in the method script to make snapshot titles
pretty much whatever you want. I think he made a good compromise
choice between simplicity and clarity in the current titling system.
Remember that the Time
On Thu, Apr 16, 2009 at 12:26 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Thu, 16 Apr 2009, Uwe Dippel wrote:
>
>>
>> What this thread actually shows, alas, is that ZFS is rocket science.
>> In 2009, one would expect a file system to 'just work'. Why would
>> anyone want to hav
On Thu, 16 Apr 2009, Uwe Dippel wrote:
What this thread actually shows, alas, is that ZFS is rocket science.
In 2009, one would expect a file system to 'just work'. Why would
anyone want to have to 'status' it regularly, in case 'scrub' it, and
For common uses, ZFS is not any more complicated
Frank Middleton wrote:
Experimenting with OpenSolaris on an elderly PC with equally
elderly drives, zpool status shows errors after a pkg image-update
followed by a scrub. It is entirely possible that one of these
drives is flaky, but surely the whole point of a zfs mirror is
to avoid this? It se
>If you do not have any problems ZFS will just work. If you have
>problems ZFS will =B6how them to you much better than EXT3, FFS, UFS or
>other traditional filesystem. And often fix them for you. In many
>cases you would get corrupted data or have to run fsck for the same
>error on FFS/UFS.
As m
On Thu, Apr 16, 2009 at 11:38, Uwe Dippel wrote:
> On Thu, Apr 16, 2009 at 1:05 AM, Fajar A. Nugraha wrote:
>
> [...]
>
> Thanks, Fajar, et al.
>
> What this thread actually shows, alas, is that ZFS is rocket science.
> In 2009, one would expect a file system to 'just work'. Why would
> anyone wa
On Thu, Apr 16, 2009 at 1:05 AM, Fajar A. Nugraha wrote:
[...]
Thanks, Fajar, et al.
What this thread actually shows, alas, is that ZFS is rocket science.
In 2009, one would expect a file system to 'just work'. Why would
anyone want to have to 'status' it regularly, in case 'scrub' it, and
if s
>Quite. Sounds like an architectural problem. This old machine probably
>doesn't have ecc memory (AFAIK still rare on most PCs), but it is on
>a serial UPS and isolated from shocks, and this has happened more
>than once. These drives on this machine recently passed both the purge
>and verify cycl
22 matches
Mail list logo
