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
> 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
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
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
>> 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
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
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
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
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
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
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
11 matches
Mail list logo