I only stumbled on this thread by accident. If you have problems
which involve Vinum, please copy me, and I may have input.
On Friday, 19 May 2000 at 7:55:37 +0200, Bernd Walter wrote:
> On Fri, May 19, 2000 at 06:24:39AM +0200, Niels Chr. Bank-Pedersen wrote:
>> On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote:
>>> On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote:
>>>> On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote:
>>>>> Does vinum list saying that one subdisk of your R5 volume is down?
>>>>
>>>> 5 subdisks:
>>>> S raid5.p0.s0 State: up PO: 0 B Size: 4133 MB
>>>> S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB
>>>> S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB
>>>> S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB
>>>> S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB
>>>>
>>>> - But since my first attempt to initialize the plex crashed the
>>>> box while only da5se1 was missing, I did a "verify media" from
>>>> the SCSI ctrl. BIOS, and did find errors. They were all successfully
>>>> remapped, though.
>>>
>>> I thought about a parity corrpution bug that there was in history.
>>> But as all drives are up and they are freshly initialized there are 2
>>> arguments why your problems should be different.
>>> Maybe one drive crashed and the system paniced before vinum was able to update
>>> the state database on the drives.
>>> Did you saw anything unusual on the console before the panic message?
>>
>> <snip>
>> - after obliterating the vinum configuration I created the volume
>> without da5, and I have now successfully copied 250+MB to the filesystem.
>>
>> I would have thought that hardware errors like this could be handled
>> in a slightly more controlled manner, though.
>
> At this moment there is no sign of a hardware error.
> The panic itself means that the filessytem allocated a block which
> already was allocated. Usually it means that the data on the drive
> got corrupted while mounted.
>
> You should be carefully testing the volume before copying important
> data to it. In my expirience I can say that using softupdates
> stresses the I/O system much more than the standard way so it makes
> sense to test with softupdates.
I recently fixed a number of problems in RAID-5. Can you give me
details of the problems you've been having, and the date of the sup?
Since this is -CURRENT, I assume that's the version of the system too.
As far as soft updates goes, basically it's incompatible with Vinum,
since there's currently no way of ensuring the sequence of writes
across a number of disks. I'm thinking of ways of doing it, but they
will cause significant loss in performance. There should be no
problems as long as there isn't a crash, of course :-)
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
