"Jared D. McNeill" writes:
> On Mon, 12 Mar 2001, Greg Oster wrote:
> > Ya... "sucky numbers" here...
> > If this is a freshly created set (i.e. no real data on it yet) then
> > maybe try something like:
> 
> I already have a bunch of junk on it, so I can't do that...

:-/

> > for the disklabel, and fix up the other numbers to match.  (you'll need to
> > newfs it again..)  In your other email you said:
> >
> > > Hmm, I just ran '/sbin/disklabel raid0' and it gave me a message like it
> > > was creating a fresh label. That's not supposed to happen, and I'm pretty
> > > sure the following isn't mine (although I am using raid0d):
> >
> > If it had a label before, then maybe something is eating that label!??!!?
> > That would be Bad... :(  Is this the first time you've tried to extract
> > that file on this system, and/or the first time you've noticed this perf
> > problem?  (I'm guessing it's the 'bad sector/track/cylinder' numbers, but
> > if something is eating the disklabel, then it could be something else too..
> )
> 
> It's not just this one file -- any tar file (using tar or pax), moving a
> directory to the array, creating a directory (mkdir foo took something
> like 12 seconds, but rmdir foo took almost no time at all). cvs is also
> slow.. but if I download a file with for example ftp, it comes through
> at full speed.

That sounds like PR#11989 all right... :(

> I didn't notice this until I restarted the machine earlier today..
> 
> Thanks,
> Jared

Later...

Greg Oster