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
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
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
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)
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
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/
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)
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 --
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...(Continue reading)> 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
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
RSS Feed1 | |
|---|---|
2 | |
2 | |
3 | |
1 | |
1 | |
2 | |
9 | |
1 | |
2 | |
4 | |
2 | |
7 | |
12 | |
4 | |
11 | |
1 | |
29 | |
1 | |
10 | |
3 | |
14 | |
16 | |
2 | |
1 | |
5 | |
2 | |
48 | |
6 | |
6 | |
11 | |
3 | |
19 | |
22 | |
27 | |
1 | |
1 | |
1 | |
5 | |
9 | |
26 | |
21 | |
2 | |
2 | |
8 | |
2 | |
4 | |
18 | |
6 | |
43 | |
5 | |
2 | |
7 | |
8 | |
16 | |
8 | |
6 | |
4 | |
15 | |
4 | |
5 | |
6 | |
14 | |
4 | |
21 | |
3 | |
2 | |
14 | |
11 | |
6 | |
10 | |
13 | |
35 | |
4 | |
11 | |
36 | |
4 | |
19 | |
9 | |
2 | |
1 | |
15 | |
35 | |
1 | |
2 | |
12 |
