On Tuesday, 17 February 2004 at 11:39:26 +1100, Tony Frank wrote:
> On Tue, Feb 17, 2004 at 09:51:30AM +1030, Greg 'groggy' Lehey wrote:
>> On Monday, 16 February 2004 at 22:04:44 +1100, Tony Frank wrote:
>>> The original config looked as so:
>>>
>>> volume data
>>> plex name data.p0 org raid5 984s vol data
>>> sd name data.p0.s0 drive eightgig plex data.p0 len 8802864s driveoffset 6335201s 
>>> plexoffset 0s
>>> sd name data.p0.s1 drive vinumdrive0 plex data.p0 len 8802864s driveoffset 265s 
>>> plexoffset 984s
>>> sd name data.p0.s2 drive vinumdrive1 plex data.p0 len 8802864s driveoffset 265s 
>>> plexoffset 1968s
>>> sd name data.p0.s3 drive vinumdrive2 plex data.p0 len 8802864s driveoffset 265s 
>>> plexoffset 2952s
>>> sd name data.p0.s4 drive vinumdrive3 plex data.p0 len 8802864s driveoffset 265s 
>>> plexoffset 3936s
>>>
>>> Now after each system reboot I see messages on system console from vinum.
>>> (they are not logged in vinum_history or messages)
>>
>> These messages should appear in /var/log/messages.  Have you changed
>> your syslogd.conf?
>
> No, default 4.9 config file, the vinum messages do not show up in 'dmesg' either.
> I have changed to include the 'all.log' and 'console.log' in the syslogd.conf so
> I will see if that changes this behaviour.

Strange.  It works fine for me:

Feb 17 17:28:23 monorchid /kernel: vinum: loaded
Feb 17 17:28:28 monorchid /kernel: vinum: reading configuration from /dev/da1s4h
Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da2s4h
Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da3s4h
Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da4s4h

>>> vinum: updating configuration from /dev/ad0s1h
>>> #(repeated for all 6 drives)
>>> vinum: removing 2560 blocks of partial stripe at the end of data.p0
>>
>> Yes, this is a feature, not a bug.
>
> While I accept this for a striped plex made up with subdisk of unequal length,
> I had already taken that into account, hence the original subdisk length:
>  8946 * 984 = 8802864

OK.  I didn't go through the calculations.

> As I understand it, this should have resulted in a whole number of
> stripes.  I have 5 subdisks so I'm not sure if I should have
> factored that into my calculations?

No, that makes no difference.

>>> A "vinum printconfig" now shows difference values for the subdisks.
>>> This value has changed after each reboot.
>>> Current relevant parts of 'printconfig' are:
>>> volume data
>>> plex name data.p0 org raid5 984s vol data
>>> sd name data.p0.s0 drive eightgig plex data.p0 len 8799978s driveoffset 6335201s 
>>> plexoffset 0s
>>> sd name data.p0.s1 drive vinumdrive0 plex data.p0 len 8799486s driveoffset 265s 
>>> plexoffset 984s
>>> sd name data.p0.s2 drive vinumdrive1 plex data.p0 len 8799158s driveoffset 265s 
>>> plexoffset 1968s
>>> sd name data.p0.s3 drive vinumdrive2 plex data.p0 len 8798420s driveoffset 265s 
>>> plexoffset 2952s
>>> sd name data.p0.s4 drive vinumdrive3 plex data.p0 len 8797600s driveoffset 265s 
>>> plexoffset 3936s

OK, I tried almost exactly the same thing.  My disks are fractionally
smaller than yours, so I took a different integral number of stripes.
I didn't get any messages, and the config now looks like:

volume data
plex name data.p0 org raid5 984s vol data
sd name data.p0.s0 drive drive1 plex data.p0 len 8374824s driveoffset 265s plexoffset 
0s
sd name data.p0.s1 drive drive2 plex data.p0 len 8374824s driveoffset 265s plexoffset 
984s
sd name data.p0.s2 drive drive3 plex data.p0 len 8374824s driveoffset 265s plexoffset 
1968s
sd name data.p0.s3 drive drive4 plex data.p0 len 8374824s driveoffset 265s plexoffset 
2952s
sd name data.p0.s4 drive drive5 plex data.p0 len 8374824s driveoffset 265s plexoffset 
3936s

I've stopped and started vinum a couple of times, and all works well.
I then removed the objects and tried again with subdisks 4 sectors
longer.  Vinum gives the message:

vinum: removing 16 blocks of partial stripe at the end of data.p0

printconfig is then identical with the previous version.

>> This is a bug, not a feature.  I'll try to take a look at it today.
>
> Please advise if I can help - I have plenty of free time this week
> and am willing to get my hands dirty.

Hmm.  Unfortunately, I don't have much time for the rest of the week.
Does this mean you're not coming to the AUUG security symposium in
Canberra?

> Another item (which I think I read about somewhere but can no longer
> find the reference) is that after a reboot the vinum drives all
> reference da0h ad2h etc rather than the original value of ad2s1h
> da0s1h.

That in itself is not a worry.  It's the way Vinum works (the two are
equivalent).

> Also after the reboot, each drive is shown as 100% free which is a
> concern.

That is indeed a concern.

There's obviously something going on here which isn't immediately
obvious.  Take a look at
http://www.vinumvm.org/vinum/how-to-debug.html and send me the
information I ask for there, and maybe we can track it down.

Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address and phone numbers.

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to