Andrew Doran | 1 Feb 03:49 2009
Picon

Re: WABPL tstile/performance issues...[LONG]

On Sat, Jan 31, 2009 at 05:45:21PM -0600, Greg Oster wrote:

> Additional thoughts?  Is nuking the FSYNC_RECLAIM the right check?
> (the above code will still do the right thing if FSYNC_RECLAIM is 
> set, since it will still be keying off of anything being in the 
> &vp->v_dirtyblkhd list)

I can't see any good reason for the FSYNC_RECLAIM check.

Andrew

matthew green | 1 Feb 12:44 2009
Picon

re: WABPL tstile/performance issues...[LONG]


   On Sat, Jan 31, 2009 at 05:45:21PM -0600, Greg Oster wrote:

   > Additional thoughts?  Is nuking the FSYNC_RECLAIM the right check?
   > (the above code will still do the right thing if FSYNC_RECLAIM is 
   > set, since it will still be keying off of anything being in the 
   > &vp->v_dirtyblkhd list)

   I can't see any good reason for the FSYNC_RECLAIM check.

for my simple test case, "make depend" on a dual processor ultra60,
i see a significant improvement with this patch applied:

-current:

175.148u 73.308s 2:22.59 174.2% 0+0k 0+710io 999pf+0w
176.455u 71.882s 2:24.27 172.1% 0+0k 0+761io 999pf+0w
175.614u 72.534s 2:23.06 173.4% 0+0k 0+746io 999pf+0w

-current + patch:

176.574u 70.956s 2:06.02 196.4% 0+0k 0+62io 999pf+0w
177.403u 69.977s 2:05.74 196.7% 0+0k 0+63io 999pf+0w
178.439u 72.903s 2:07.56 197.0% 0+0k 0+63io 999pf+0w

.mrg.

Dennis den Brok | 1 Feb 17:04 2009
Picon

Re: 5.0/i386 regressions

Christos Zoulas <christos <at> astron.com> schrieb:
> No, please file PR's with the dmesg...
>

At last I did this, featuring the problem's cause (without an idea
of a fix, though): a(n arbitrary) CF card plugged in prevents the 
machine from powering off properly.

PR#40531

Regards,
--
Dennis den Brok

Ignatios Souvatzis | 1 Feb 18:33 2009
Picon

no ndis* at cardbus?

I was wondering whether I could just use COMPAT_NDIS with a D-LINK
DWL-650G+ instead of waiting for an acx1xx at cardbus driver...

However config(8) refuses to attach ndis at cardbus as of netbsd-4 and,
afaict from reading the source, netbsd-5. What exactly would be needed
to create a cardbus attachment for ndis?

	-is
--

-- 
seal your e-mail: http://www.gnupg.org/

Jim Wise | 2 Feb 02:47 2009

__vfork14()


Quick question, out of curiosity, about NetBSD's vfork():

In 1998, we switched vfork() back from the 4.4 semantics (Copy-on-Write
until exec) to the traditional BSD semantics (shared address space
between parent and child until exec()).  I'm curious about the how this
is used:

  -- was this an optimization, with code working pretty much as before,
     but gaining speed from not doing a bunch of unneeded Copy-on-Write
     setup?

  -- are there programs in-tree which depend on the shared address space
     semantics?

  -- are there common third-party apps which do?

  -- what do other systems do?

Needless to say, there's no lurking change behind this question -- just
wondering... 

--

-- 
				Jim Wise
				jwise <at> draga.com
matthew green | 2 Feb 02:51 2009
Picon

re: __vfork14()


     -- was this an optimization, with code working pretty much as before,
        but gaining speed from not doing a bunch of unneeded Copy-on-Write
        setup?

it was clearly an optimisation.  i'm sure this or some other
list has benchmark results for this, back from then.

     -- are there programs in-tree which depend on the shared address space
        semantics?

one hopes not :-)  infact, /bin/sh does not use it currently
because of this.  see the several attempts to fix it that have
been backed out :-)

     -- are there common third-party apps which do?

i don't know, but again, i hope not.

     -- what do other systems do?

don't know.

.mrg.

Roland Dowdeswell | 2 Feb 03:04 2009

Re: __vfork14()

On 1233539464 seconds since the Beginning of the UNIX epoch
matthew green wrote:
>

>     -- are there programs in-tree which depend on the shared address space
>        semantics?
>
>one hopes not :-)  infact, /bin/sh does not use it currently
>because of this.  see the several attempts to fix it that have
>been backed out :-)

We eventually got it right.  It is the default in /bin/sh.  It makes
simple shell scripts a lot faster if the programs executed don't do
much work, .e.g. /bin/[, /bin/echo, etc.

The code has to be conditionally compiled to know whether vfork(2) has
shared address space or COW semantics for various reasons.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

Edgar Fuß | 2 Feb 17:56 2009
Picon

Again: panic: softdep_deallocate_dependencies: unrecovered I/O error (but no I/O error)

On Mon, Nov 24, 2008 at 10:51:15PM +0100, Edgar Fuß wrote:
> raid1: IO failed after 5 retries
> raid1: IO failed after 5 retries
> raid1: IO failed after 5 retries
> /export/mail: got error 5 while accessing filesystem
> panic: softdep_deallocate_dependencies: unrecovered I/O error
> 
> The funny thing is there's actually no I/O error (at least nothing in dmesg).
> 
Nearly the same today (same machine, same raid, different file system).
Again, this happened during high activity on the raid.

However, this time, I do have a dump.

What should I investigate in the dump?

der Mouse | 2 Feb 20:15 2009

RAID-on-RAID

How hard would it be to make autoconfigured RAID-on-RAID work?  I had a
look at the code and it looks to me as though it'd just be a question
of scanning new RAID units for partitions of type RAID as they get
autoconfigured, repeating until nothing more happens.

Am I missing something?  I have a machine (the same one on which I've
been doing all my recent RAIDframe playing) on which it would be useful
to autoconfigure RAID-on-RAID.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Greg Oster | 2 Feb 20:27 2009
Picon
Picon

Re: Again: panic: softdep_deallocate_dependencies: unrecovered I/O error (but no I/O error)

Edgar =?iso-8859-1?B?RnXf?= writes:
> On Mon, Nov 24, 2008 at 10:51:15PM +0100, Edgar Fu=DF wrote:
> > raid1: IO failed after 5 retries
> > raid1: IO failed after 5 retries
> > raid1: IO failed after 5 retries
> > /export/mail: got error 5 while accessing filesystem
> > panic: softdep_deallocate_dependencies: unrecovered I/O error
> >=20
> > The funny thing is there's actually no I/O error (at least nothing in d=
> mesg).
> >=20
> Nearly the same today (same machine, same raid, different file system).
> Again, this happened during high activity on the raid.

:(

> However, this time, I do have a dump.
> 
> What should I investigate in the dump?

I'd like to know what's in raidPtrs[0] (or raidPtrs[1] or whatever 
number the RAID set is).  In particular, knowing what's in the 
raidPtrs[0].Queues structure might be useful.

The trick is to figure out why a getiobuf() call returned NULL, or 
whether or not the diskqueuedata pool was exhausted... 

Feel free to contact me off-line about this...

Later...
(Continue reading)


Gmane