Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?

2011-12-10 Thread Brian Buhrow
Hello. I notice that most, if not all, of the network drivers in NetBSD have interface counters which they use to track things like collisions, CRC errors, framing errors, etc. It looks like these counters, and the framework for displayng these counters has been in NetBSD for well over 10

Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?

2011-12-10 Thread Izumi Tsutsui
> drivers. Is there a reason all of these counting facilities are not > enabled by default in GENERIC kernels? Does using these counters impose such > a > performance penalty that general use was deemed too crippling? Do you try any benchmark? (by ttcp(1) etc.) During mec(4) (on sgimips O2) d

Re: Use consistent errno for read(2) failure on directories

2011-12-10 Thread Christos Zoulas
In article <20111209083354.ga2...@lynche.sis.pasteur.fr>, Nicolas Joly wrote: >-=-=-=-=-=- > > >Hi, > >According to the online OpenGroup specification for read(2) available >at [1], read(2) on directories is implementation dependant. If >unsupported, it shall fail with EISDIR. > >Not all our file

Re: Use consistent errno for read(2) failure on directories

2011-12-10 Thread David Holland
On Fri, Dec 09, 2011 at 09:33:54AM +0100, Nicolas Joly wrote: > According to the online OpenGroup specification for read(2) available > at [1], read(2) on directories is implementation dependant. If > unsupported, it shall fail with EISDIR. > > Not all our file systems comply, and return rand

Re: Use consistent errno for read(2) failure on directories

2011-12-10 Thread Mouse
>> According to the online OpenGroup specification for read(2) >> available at [1], read(2) on directories is implementation >> dependant. If unsupported, it shall fail with EISDIR. >> Not all our file systems comply, and return random errno values in >> this case (mostly EINVAL or ENOTSUP). How

Re: Use consistent errno for read(2) failure on directories

2011-12-10 Thread Steven Bellovin
On Dec 10, 2011, at 12:06 18PM, Mouse wrote: >>> According to the online OpenGroup specification for read(2) >>> available at [1], read(2) on directories is implementation >>> dependant. If unsupported, it shall fail with EISDIR. > >>> Not all our file systems comply, and return random errno va

Re: Lost file-system story

2011-12-10 Thread Edgar Fuß
My impression is that you are asking for the impossible. The underlying misconception (which I know very well for suffering from it myself) is that a filesystem aims at keeping the on-disc metadata consistent and that tools like fsck are intended to rapair any inconsistencies happening nonthele

Re: Lost file-system story

2011-12-10 Thread Donald Allen
On Sat, Dec 10, 2011 at 1:14 PM, Edgar Fuß wrote: > My impression is that you are asking for the impossible. > > The underlying misconception (which I know very well for suffering from it > myself) is that a filesystem aims at keeping the on-disc metadata consistent > and that tools like fsck ar

Re: Lost file-system story

2011-12-10 Thread Donald Allen
On Fri, Dec 9, 2011 at 4:33 PM, Brian Buhrow wrote: >        Hello.  Just for your edification, it is possible to break out of fsck > mid-way and reinvoke it with fsck -y to get it to do the cleaning on its > own. This whole discussion, interesting though it may be, may have occurred simply becau

Re: Use consistent errno for read(2) failure on directories

2011-12-10 Thread Nicolas Joly
On Sat, Dec 10, 2011 at 12:06:18PM -0500, Mouse wrote: > >> According to the online OpenGroup specification for read(2) > >> available at [1], read(2) on directories is implementation > >> dependant. If unsupported, it shall fail with EISDIR. > > >> Not all our file systems comply, and return ran

Re: Lost file-system story

2011-12-10 Thread Aleksej Saushev
Donald Allen writes: > On Sat, Dec 10, 2011 at 1:14 PM, Edgar Fuß wrote: >> Of course, keeping the on-disc metadata in a ``repairable'' state incurs a >> performance penalty. >> >> So you seem to be asking for the File System Holy Grail: a file >> system that is as fast as asyncronous metadata