On Wed, Jun 24, 2009 at 5:59 PM, erik quanstromquans...@quanstro.net wrote:
/boot/fossil: cacheLocalData: addr=155039 type got 0 exp 0: tag got
19383bf exp 11383bf
/boot/fossil: cacheLocalData: addr=155167 type got 0 exp 0: tag got
19383bf exp 11383bf
am i wrong in thinking that it would be
it's even neater to use a raid level that doesn't require venti
intervention.
agreed.
does venti even keep scores on the bloom filter blocks and the icache?
no, but those are soft data and can be reconstructed.
russ
does venti even keep scores on the bloom filter blocks and the icache?
no, but those are soft data and can be reconstructed.
being the paranoid type, i worry about this. does the
rebuild rate on a large (say, 1tb) venti make this a
practical strategy?
- erik
there's no question that a better strategy is to
use a 100% reliable underlying storage device.
let me know when you find one.
- erik
On Thu, Jun 25, 2009 at 9:24 AM, erik quanstromquans...@quanstro.net wrote:
does venti even keep scores on the bloom filter blocks and the icache?
no, but those are soft data and can be reconstructed.
being the paranoid type, i worry about this. does the
rebuild rate on a large (say, 1tb)
On Thu, Jun 18, 2009 at 10:10 AM, John Florenslawmas...@gmail.com wrote:
On Thu, Jun 18, 2009 at 9:45 AM, erik quanstrom quans...@quanstro.net wrote:
It seems to only happen once per boot, but not necessarily when fossil
starts responding--I've seen it a couple hours after booting, which
On Thu, Jun 18, 2009 at 9:01 AM, John Floren slawmas...@gmail.com wrote:
Our Coraid device recently lost two disks from the RAID5
configuration; while we were able to rebuild from instructions given
by support, I suspect some small amount of data was corrupted.
Since rebuilding the device a
/boot/fossil: cacheLocalData: addr=78989 type got 0 exp 0: tag got
e63eb942 exp 663eb942
/boot/fossil: cacheLocalData: addr=99457 type got 0 exp 0: tag got
150daf85 exp 150daf05
/boot/fossil: cacheLocalData: addr=68651 type got 0 exp 0: tag got
66be7fe5 exp 663e7fe5
/boot/fossil: cacheLocalData:
On Wed, Jun 24, 2009 at 12:09 PM, cinap_len...@gmx.de wrote:
/boot/fossil: cacheLocalData: addr=78989 type got 0 exp 0: tag got
e63eb942 exp 663eb942
/boot/fossil: cacheLocalData: addr=99457 type got 0 exp 0: tag got
150daf85 exp 150daf05
/boot/fossil: cacheLocalData: addr=68651 type got 0
So I went ahead and reinstalled fossil and venti--this time I went
with a RAID-10 configuration on the Coraid.
for data integrety, raid 5 is a better solution because
on a raid 10, if one block is wrong, it's a coin flip as
to which one is correct (if any). with raid 5, it's possible
to
On Wed, Jun 24, 2009 at 7:39 PM, erik quanstromquans...@coraid.com wrote:
So I went ahead and reinstalled fossil and venti--this time I went
with a RAID-10 configuration on the Coraid.
for data integrety, raid 5 is a better solution because
on a raid 10, if one block is wrong, it's a coin
Not directly related to the topic here, but this has always bugged me
about running Venti on mirrored or raided disks.
When a block on a mirrored pair doesn't match the block on its
partner, the mirroring layer has no idea which one is right, but Venti
does. Some way to export this read
/boot/fossil: cacheLocalData: addr=155039 type got 0 exp 0: tag got
19383bf exp 11383bf
/boot/fossil: cacheLocalData: addr=155167 type got 0 exp 0: tag got
19383bf exp 11383bf
am i wrong in thinking that it would be an error to have the same tag at
two different addresses?
- erik
Forgot to add that I've only seen one error on the console during all of this:
/boot/fossil: could not write super block; waiting 10 seconds
/boot/fossil: blistAlloc: called on clean block.
I get a few of these nearly every day. I've been assuming they are benign.
/boot/fossil: could not write super block; waiting 10 seconds
/boot/fossil: blistAlloc: called on clean block.
I have a few a day for the last 5 years on my home server, and one a week
on the work machine... I always ignored them.
-Steve
On Sun Jun 21 07:59:52 EDT 2009, 9f...@hamnavoe.com wrote:
Forgot to add that I've only seen one error on the console during all of
this:
/boot/fossil: could not write super block; waiting 10 seconds
/boot/fossil: blistAlloc: called on clean block.
I get a few of these nearly every
Our Coraid device recently lost two disks from the RAID5
configuration; while we were able to rebuild from instructions given
by support, I suspect some small amount of data was corrupted.
Since rebuilding the device a few days ago, every morning I have
returned to work to find my CPU/auth/file
Forgot to add that I've only seen one error on the console during all of this:
/boot/fossil: could not write super block; waiting 10 seconds
/boot/fossil: blistAlloc: called on clean block.
is that once, or every time?
- erik
On Thu, Jun 18, 2009 at 9:01 AM, John Floren slawmas...@gmail.com wrote:
Our Coraid device recently lost two disks from the RAID5
configuration; while we were able to rebuild from instructions given
by support, I suspect some small amount of data was corrupted.
Since rebuilding the device a
On Thu, Jun 18, 2009 at 9:25 AM, erik quanstrom quans...@quanstro.net wrote:
Forgot to add that I've only seen one error on the console during all of
this:
/boot/fossil: could not write super block; waiting 10 seconds
/boot/fossil: blistAlloc: called on clean block.
is that once, or
It seems to only happen once per boot, but not necessarily when fossil
starts responding--I've seen it a couple hours after booting, which
the filesystem tends to go away at night.
the failure is somewhere in blockWrite. since blockWrite
calls diskWrite and diskWrite just queues up i/o to
On Thu, Jun 18, 2009 at 9:45 AM, erik quanstrom quans...@quanstro.net wrote:
It seems to only happen once per boot, but not necessarily when fossil
starts responding--I've seen it a couple hours after booting, which
the filesystem tends to go away at night.
the failure is somewhere in
22 matches
Mail list logo
