kamel derouiche | 2 Jul 15:02 2005
Picon

kern/30449


Hi Group

What kern/30449 or Kern/number  ??

Thank You 

NetBSD is Very JIHBED, JIHEBD it is word arabic == TOP AND POWER INTELLIGENT

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Klaus Klein | 2 Jul 15:30 2005
Picon

Re: kern/30449

kamel derouiche wrote:

> What kern/30449 or Kern/number  ??

It's category and number for a problem report in the NetBSD bug database.
More information is available at http://www.netbsd.org/Misc/send-pr.html ;
a particular problem report can be retrieved by its number through
http://www.netbsd.org/Misc/query-pr.html .

- Klaus

uair | 3 Jul 04:06 2005

PSX driver

Hi:
I have a PSX pad and I want to make it work under NetBSD. I've looked around the
web and the NetBSD homepage and the nearest thing I found was a "driver" for a
SNES pad for FreeBSD (aside from drivers for PSX pads for Linux). Well, I've decided
that I'll make my own driver for my PSX pad for NetBSD using the parallel port; this is the
first time I'm going to do something like this (I have a low/medium knowledge of C/C++ coding)
and there's a lot of help/comments/sugestions I could use. First, I'll improve my C/C++ programming
skills and then I'll really start doing the driver; I've just downloaded a guide for "writing drivers
for NetBSD" by Jochen Kunz and I'll take a look to the linux drivers. Hopefully, I'll finish the driver
in the next months, but I write to you to let you know my intentions (I hope this is the right mailing list to do so).
Anyway, I'm runnig NetBSD/amd64, and the PSX pad it's plugged to the parallel port as showed in
http://www.emulatronia.com/reportajes/directpad/psxeng/ . I don't pretend to write a NetBSD quality driver
(maybe in a couple of years I'll be skilled enough) or expect that you think I'm going to, I'm just trying
to learn something more and play my xmame roms with a pad :)

Saludos

Hugo

Jeremy C. Reed | 3 Jul 07:42 2005
Picon

lpd errors not logged

Failures to print to lpd didn't give me any logging.

I noticed a few lpd errors by connecting manually to the printer (515) 
port.

These errors should have also gone to syslog:

1)  /usr/sbin/lpd: Connect from invalid port (42800)

(-W fixes above)

2) /usr/sbin/lpd: Host name for your address (192.168.0.99) unknown

lpd(8) doesn't document that and it was not logged.

3) pilchuck.reedmedia.net: /usr/sbin/lpd: Your host does not have line 
printer access

The above was caused by first line in hosts.lpd to have a minus sign. 
Maybe a hosts.lpd(5) man page is needed?

4) pilchuck.reedmedia.net: /usr/sbin/lpd: Illegal service request

Caused by own testing. I'll ignore that.

For 1, 2 and 3 above, these should by logged via syslog for easier 
troubleshooting.

Currently lpd uses its own fatal() function for many errors. Probably some 
of them should be syslogged too.
(Continue reading)

James Buchanan | 12 Jul 21:00 2005
Picon
Picon

NetBSD file system chat

Would anyone like to join in a discussion on implementing a new file 
system for NetBSD with huge file system support (> 3TB) and journaling? 
  I know soft updates on BSD systems do work like journaling, but I'm 
not knowledgeable enough to say if one or the other is superior under 
certain circumstances.  Can someone comment on this?

Since we can't know the physical disk geometry on modern disks, it 
doesn't make a lot of sense to design a file system with knowledge of 
cylinder boundaries or any other disk information.  A new file system 
should probably be a simple layout of extents of size x (probably page 
size, and configurable at file system creation time).

Can a new file system somehow be implemented in userland first before 
adding it into a kernel?

--
James

Matthias Scheler | 13 Jul 14:04 2005
Picon

Re: NetBSD file system chat

In article <42D41345.9050809 <at> iinet.net.au>,
	James Buchanan <jamesb.au <at> iinet.net.au> writes:
> Would anyone like to join in a discussion on implementing a new file 
> system for NetBSD with huge file system support (> 3TB) and journaling? 
>   I know soft updates on BSD systems do work like journaling, but I'm 
> not knowledgeable enough to say if one or the other is superior under 
> certain circumstances.

Soft dependences are a performance kludge in UFS which allows it to
work more asynchronously without risking data integrity. They don't
provide the protection against unclean system shutdown that a
journaling file system does.

> Can a new file system somehow be implemented in userland first before 
> adding it into a kernel?

Yes, it can. Userland programs can present itself to the kernel as
a NFS server. amd(8) and "pkgsrc/net/sharity-light" use such an
approach.

	Kind regards

--

-- 
Matthias Scheler                                  http://scheler.de/~matthias/

Mike Cheponis | 13 Jul 20:44 2005

Re: NetBSD file system chat

On Wed, 13 Jul 2005, James Buchanan wrote:

> Since we can't know the physical disk geometry on modern disks,

I don't believe this is true.

If one were willing to measure transfer rates for a variety of sectors, I suspect an exact map of the disk
could be determined.

If the disk can tell you when it is re-mapping a sector, one could adjust the algorithm.

I believe this uncertainty can be completely removed.

> it doesn't 
> make a lot of sense to design a file system with knowledge of cylinder 
> boundaries or any other disk information.  A new file system should probably 
> be a simple layout of extents of size x (probably page size, and configurable 
> at file system creation time).

> Can a new file system somehow be implemented in userland first before adding 
> it into a kernel?

Yes.  Simulate it.

> --
> James

-Mike

p.s. I have for years now advocated a tighter coupling between the VM and a huge FS.  Others with less vision
(Continue reading)

David Brownlee | 13 Jul 22:02 2005
Picon

Re: NetBSD file system chat

On Wed, 13 Jul 2005, Mike Cheponis wrote:

> On Wed, 13 Jul 2005, James Buchanan wrote:
>
>> Since we can't know the physical disk geometry on modern disks,
>
> I don't believe this is true.
>
> If one were willing to measure transfer rates for a variety of sectors, I 
> suspect an exact map of the disk could be determined.

 	Useful reference for this:

 	http://www.pdl.cmu.edu/PDL-FTP/DriveChar/traxtent.pdf

 	    Track-aligned extents (traxtents) utilize disk-specific
 	    knowledge to match access patterns to the strengths of
 	    modern disks. By allocating and accessing related data
 	    on disk track boundaries, a system can avoid most ro-
 	    tational latency and track crossing overheads. Avoiding
 	    these overheads can increase disk access efficiency by up
 	    to 50% for mid-sized requests (100–500 KB). This paper
 	    describes traxtents, algorithms for detecting track bound-
 	    aries, and some uses of traxtents in file systems and video
 	    servers.

--

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --
James Buchanan | 14 Jul 00:09 2005
Picon
Picon

Re: NetBSD file system chat

Mike Cheponis wrote:
> I don't believe this is true.
> 
> If one were willing to measure transfer rates for a variety of sectors, 
> I suspect an exact map of the disk could be determined.
> 
> If the disk can tell you when it is re-mapping a sector, one could 
> adjust the algorithm.
> 
> I believe this uncertainty can be completely removed.

Is it worth having all this extra cruft to measure sector transfers in 
the file system for such a small payoff?  When does all this extra 
complexity become simply complexity and overhead for certain transfers? 
  The paper quoted by another poster says that performance can be 
increased by up to 50% for mid-sized requests (100 - 500KB).  That would 
only be useful if, like you say, we can get tight VM/FS integration 
where lots of transfers can be bundled up together.  And then, the disk 
extents would need to be contiguous.  Is it really worth it?  And what 
is *up to* 50%?  How many milliseconds, at best?

I don't believe it's worth it.  But, I am by no means an expert on 
disks, so if anyone knows anything I don't know... ;-)

> Yes.  Simulate it.

OK, thanks.  I'll look into it.  Another poster has pointed out 
something interesting that I'll check out.

> p.s. I have for years now advocated a tighter coupling between the VM 
(Continue reading)

James Buchanan | 14 Jul 00:10 2005
Picon
Picon

Re: NetBSD file system chat

Matthias Scheler wrote:
> Soft dependences are a performance kludge in UFS which allows it to
> work more asynchronously without risking data integrity. They don't
> provide the protection against unclean system shutdown that a
> journaling file system does.

Time to get rid of soft updates. :)

> Yes, it can. Userland programs can present itself to the kernel as
> a NFS server. amd(8) and "pkgsrc/net/sharity-light" use such an
> approach.

Thanks very much for this.  I'll play around with it and see what I can 
do there.

--
James


Gmane