Re: requesting vinum help

On Wed, 26 Nov 2003, Poul-Henning Kamp wrote:

> In message <447049543.1069836265_at_[192.168.1.20]>, "Joel M. Baldwin" writes:
> 
> >I was trying to use some restraint and not rant and rave in public like
> >I wanted to do.  I'm rather miffed that nothing appeared in UPDATING.
> >Rather than an unproductive public RANT I thought I'd ask for private assistance.
> >I can post a summary afterwards if you like, or even better write a better
> >FAQ/tutorial on vinum.
> 
> Joel,
> 
> The problem is that vinum is hot political potato in the project.
> 
> In the eyes of a fair number of competent people, vinum has never
> quite "made it".  I think most of them have given it a shot and
> lost data to it.  Some of them, after looking in the code to "fix
> the problem", said "never again!" and now hate vinum of a good
> heart.
> 
> Greg has disclaimed maintainership of vinum some time ago for reasons
> of politics, and he now is of the opinion that it is everybodys
> (elses) task to maintain vinum.  Everybody else disagree and belive
> that "vinum is very much Gregs own problem".
> 
> With Greg being a core_at_ member, and well known for his ability to
> talk an acturan megadonkey into taking a stroll after first having
> talked its legs off about procedural issues, "Doing something about
> vinum" is permanently on the "we should really..." list and everybody
> hopes somebody else will "deal with it".  Of course, in the end
> nobody does.
> 
> As matters stand, we are doing our users a disservice by continuing
> to pretend everything is OK when in fact it is not at all.
> 
> Personally, I think vinum(8) should not be in our 5-STABLE featureset
> if it is not brought up to current standards and actively maintained.
> 
> But at the very least we should have the release notes reflect that
> vinum is unmaintained and belived to unreliable and have vinum(8)
> issue a very stern warning to people along those lines.
> 
> I'm sure that a major bikeshed will now ensue and people will argue
> that there is a lot more to this dispute than what I've said above.
> 
> They're right of course, this is a very short summary :-)
> 
> Poul-Henning
> 
> 


I am using vinum atm, and I am having serious problems with it.  After 
about 16 hrs of writing data to a vinum volume via NFS at a constant data 
stream of 200k/sec and reading at 400k/sec at the same time, the whole 
machine just freezes, hard.  The only thing I can do is reboot.  This 
behavior appears in 4.8 and 5-CURRENT.  I have no indication of what is 
wrong, or how to go about finding it out.  The problem is either with NFS 
or Vinum, and I'm leaning towards Vinum (because of the failure in both 
-STABLE and -CURRENT).

I'm not the kind of person that relies on other people, and I like to fix 
my own problems, but this is a problem which I cannot fix at this time.  
So, I'm planning to look through the code of vinum and start messing with 
it to figure out how it works and how to debug it.  This is how important 
Vinum is to me at the moment.

I'm not a kernel coder, or an intense coder in general (but I'm proficient 
in C/C++, and have used FreeBSD for quite some years now), so I'm reading  
the Kernel Developer's Handbook as a starting point.  If anyone has other 
online documentation on FreeBSD Kernel programming, it would be much 
appreciated.  

What would also be appreciated is an overall "map" of how vinum is 
organized and how it works.  Otherwise, I'll have to painstaikingly 
go through the code and figure everything out little by little 
(which I plan to do, but if you know how Vinum works, everything is much 
easier, makes sense right away, and takes less time).

Thank you in advance.

Cosmin Stroe.