> /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
> 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 rea
On Wed, Jun 24, 2009 at 7:39 PM, erik quanstrom 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 flip as
> to whi
> 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 deter
On Wed, Jun 24, 2009 at 12:09 PM, 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 exp 0: tag got
>
/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: a
On Thu, Jun 18, 2009 at 9:01 AM, John Floren 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 few days ago, e
On Thu, Jun 18, 2009 at 10:10 AM, John Floren wrote:
> On Thu, Jun 18, 2009 at 9:45 AM, erik quanstrom 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
> it might be surprising that, e.g.,
> Â Â Â Â mount -c '#D/ssl/2/data' /mnt/term
> is not unmounted, but the mntpt isn't /mnt,
> it's /mnt/term. Â things below /mnt are not
> accessable because we must walk from the
> root.
In fact, this is the most confusing point... ;-)
Thanks for explanati
> it seems I still do not fully understand namespaces.
> But this sequence seems strange to me:
>
> cdfs -d /dev/sdD0
> unmount /mnt/cd
>
> ...everything is OK.
>
> cdfs -d /dev/sdD0
> unmount /mnt
>
> ...I unmounted wrong directory...
>
> cdfs -d /dev/sdD0
> cdfs: openscsi '/dev/sdD0': '/dev/
Hi all,
it seems I still do not fully understand namespaces.
But this sequence seems strange to me:
cdfs -d /dev/sdD0
unmount /mnt/cd
...everything is OK.
cdfs -d /dev/sdD0
unmount /mnt
...I unmounted wrong directory...
cdfs -d /dev/sdD0
cdfs: openscsi '/dev/sdD0': '/dev/sdD0/raw' device or o
11 matches
Mail list logo