On Mon, Feb 11, 2008 at 12:39:08PM -0700, Joe Peterson wrote:
Gavin Atkinson wrote:
Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt
block before or after the datestamp of the file it was found within?
i.e. was the corrupt block on the disk before or after the mp3 was
Joe Peterson wrote:
Gavin Atkinson wrote:
Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt
block before or after the datestamp of the file it was found within?
i.e. was the corrupt block on the disk before or after the mp3 was
written there?
Hi Gavin, those dated are
On Tue, Mar 04, 2008 at 07:25:35AM -0600, Eric Anderson wrote:
I'm starting to think there is a timing issue or some such problem with
ZFS, since I can use the same drives in a gmirror with UFS, and never have
any data problems (md5 checksums confirm it over-and-over). I highly doubt
that
Eric Anderson wrote:
I'm starting to think there is a timing issue or some such problem with
ZFS, since I can use the same drives in a gmirror with UFS, and never
have any data problems (md5 checksums confirm it over-and-over). I
highly doubt that everyone is seeing similar issues and it
Joe Peterson wrote:
*cut*
I suppose the best ZFS could then do is retry the write (if its
failure was even detected - still not sure if ZFS does a re-check of the
disk data checksum after the disk write), not knowing until the later
scrub that the block had corrupted a file.
*cut*
Gavin Atkinson wrote:
Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt
block before or after the datestamp of the file it was found within?
i.e. was the corrupt block on the disk before or after the mp3 was
written there?
Hi Gavin, those dated are later than the original
On Fri, 2008-02-08 at 17:15 -0700, Joe Peterson wrote:
Chris Dillon wrote:
That is a chunk of a Mozilla Mork-format database. Perhaps the
Firefox URL history or address book from Thunderbird.
Interesting (thanks to all who recognized Mork). I do use Firefox and
Thunderbird, so it's
In my experimentation with the ZFS filesystem, I encountered one case of
a file block with a checksum mismatch. Doing a zpool scrub revealed
it, and trying to read the file yielded an error - only the part of the
file before the bad block was read (ZFS aborts reading at this point,
which makes
Mark Day wrote:
Based on the subset of data you posted, the bad data looks like ASCII
text.
The bad data from offset a to a000f is:
${138AFE{@
@$$}1
The bad data from offset af6c1 to af6c8 is:
392A9}@
I don't recognize the content beyond that, but I'd guess that somehow
the
* Joe Peterson [EMAIL PROTECTED] [080208 14:58] wrote:
Mark Day wrote:
Based on the subset of data you posted, the bad data looks like ASCII
text.
The bad data from offset a to a000f is:
${138AFE{@
@$$}1
The bad data from offset af6c1 to af6c8 is:
392A9}@
I don't
I'd say that's the mork database format [1,2], as used by Mozilla
products, for example in the Firefox history.dat file.
- Bartosz
[1] http://www.mozilla.org/mailnews/arch/mork/primer.txt
[2] http://www.jwz.org/hacks/mork.pl
___
Joe Peterson wrote:
In my experimentation with the ZFS filesystem, I encountered one case of
a file block with a checksum mismatch. Doing a zpool scrub revealed
it, and trying to read the file yielded an error - only the part of the
file before the bad block was read (ZFS aborts reading at this
On Feb 8, 2008, at 2:29 PM, Joe Peterson wrote:
For one thing (as I mentioned), only 65536 bytes are bad (and it's
exactly this many, with a few good bytes thrown in, but not far from
what matches random chance would produce. Also, all bad bytes have a
zero in the high bit - interesting?
Quoting Joe Peterson [EMAIL PROTECTED]:
I dumped the whole bad section as a string, and here's (partly) what I get:
[...edited for brevity...]
@$${138B8B{@
(21470=Thu Jan 24 23:20:58 2008)
[117:^80(^91^21470)]
@$$}138B8B}@
@$${138C18{@
In the last episode (Feb 08), Joe Peterson said:
Mark Day wrote:
Based on the subset of data you posted, the bad data looks like
ASCII text. The bad data from offset a to a000f is:
${138AFE{@
@$$}1
The bad data from offset af6c1 to af6c8 is:
392A9}@
I don't recognize the
Chris Dillon wrote:
That is a chunk of a Mozilla Mork-format database. Perhaps the
Firefox URL history or address book from Thunderbird.
Interesting (thanks to all who recognized Mork). I do use Firefox and
Thunderbird, so it's feasible, but how the heck would a piece of one of
those files
Joe Peterson wrote:
Chris Dillon wrote:
That is a chunk of a Mozilla Mork-format database. Perhaps the
Firefox URL history or address book from Thunderbird.
Interesting (thanks to all who recognized Mork). I do use Firefox and
Thunderbird, so it's feasible, but how the heck would a piece
Julian Elischer wrote:
it could be an old file..
what kind of disks?
It's a Seagate ST3500630A parallel ATA drive.
I had a scenario where 3ware controllers were just failing to write to
a drive in the array, so old data showed through.
I have an Intel ICH4 controller - nothing unusual.
Joe Peterson wrote:
Julian Elischer wrote:
it could be an old file..
what kind of disks?
It's a Seagate ST3500630A parallel ATA drive.
I had a scenario where 3ware controllers were just failing to write to
a drive in the array, so old data showed through.
I have an Intel ICH4 controller -
19 matches
Mail list logo
