On Jun 23, 2011, at 23:19 , Michael van Elst wrote:
> s...@cs.columbia.edu (Steven Bellovin) writes:
>
>> The point is that when dealing with raw devices, you take what the hardware
>> gives you. 6th Edition could have detected this and copied the user data
>> into a properly-aligned buffer, wi
f...@netbsd.org (Erik Fair) writes:
>On Jun 23, 2011, at 23:19 , Michael van Elst wrote:
>> s...@cs.columbia.edu (Steven Bellovin) writes:
>>
>>> The point is that when dealing with raw devices, you take what the hardware
>>> gives you. 6th Edition could have detected this and copied the user d
On Thu, Jun 23, 2011 at 06:06:14PM +, David Holland wrote:
> I've been thinking that the nfs client problems I've been seeing,
> which seem to be callout-related, are maybe connected, as could be the
> odd problem mrg has been having with raidframe.
>
> Do we have a debug hook or other method
Date:Fri, 24 Jun 2011 00:09:58 -0700
From:Erik Fair
Message-ID:
| Oh, and as noted before, through the block interface, you could do
| arbitrary (up to ... was it 64KB?
Just under that, the count arg on read/write was an int after all (on
a 16 bit system). Nega
On Fri, 24 Jun 2011, Manuel Bouyer wrote:
On Thu, Jun 23, 2011 at 06:06:14PM +, David Holland wrote:
I've been thinking that the nfs client problems I've been seeing,
which seem to be callout-related, are maybe connected, as could be the
odd problem mrg has been having with raidframe.
Do w
>> Oh, I was talking about current NetBSD where block devices are a
>> second class citizen, soon to be abolished if someone finds enough
>> round tuits.
> Yes, so it keeps being said. It would truly be a pity to see that
> happen.
Why?
/~\ The ASCII Mouse
\ / Ribbon
With the attached diff vnd(4) devices will work on sparse files.
- Make the strategy decision a device flag and set to VNF_USE_VN_RDWR for
files known to be sparse.
- Change handle_with_rdwr() to use POSIX_FADV_NOREUSE advise to disable
read ahead.
- Keep the amount of mapped pages below 1 MByt
On Fri, Jun 24, 2011 at 07:50:35AM +, Michael van Elst wrote:
>
> Similar to raw devices in performance, I/O caching, and without the
> hardware constraints regarding block sizes or alignment. I.e. something
> that lets you treat disk contents like a regular file.
At least for NetBSD, that's
On Fri, Jun 24, 2011 at 08:14:00AM -0700, Hisashi T Fujinaka wrote:
> On Fri, 24 Jun 2011, Manuel Bouyer wrote:
>
> >On Thu, Jun 23, 2011 at 06:06:14PM +, David Holland wrote:
> >>I've been thinking that the nfs client problems I've been seeing,
> >>which seem to be callout-related, are maybe
On Fri, Jun 24, 2011 at 11:33:51AM -0400, der Mouse wrote:
> >> Oh, I was talking about current NetBSD where block devices are a
> >> second class citizen, soon to be abolished if someone finds enough
> >> round tuits.
> > Yes, so it keeps being said. It would truly be a pity to see that
> >
On Fri, Jun 24, 2011 at 12:11:22PM +0200, Manuel Bouyer wrote:
> > I've been thinking that the nfs client problems I've been seeing,
> > which seem to be callout-related, are maybe connected, as could be the
> > odd problem mrg has been having with raidframe.
> >
> > Do we have a debug hook o
On Fri, 24 Jun 2011, Manuel Bouyer wrote:
On Fri, Jun 24, 2011 at 08:14:00AM -0700, Hisashi T Fujinaka wrote:
On Fri, 24 Jun 2011, Manuel Bouyer wrote:
On Thu, Jun 23, 2011 at 06:06:14PM +, David Holland wrote:
I've been thinking that the nfs client problems I've been seeing,
which seem
On Fri, Jun 24, 2011 at 09:45:19AM -0700, Hisashi T Fujinaka wrote:
> >To see if it's the problem you'll need to enter ddb and see what the
> >per-cpu soft interrupt threads are doing.
>
> OK, do I need to add kernel debugging, etc? I've done this in the past
> but it's been a while.
ddb should b
On Fri, Jun 24, 2011 at 12:09:58AM -0700, Erik Fair wrote:
>
> Of course, if you want to talk about really slow I/O with massive latency,
> let's talk about random access to DECtapes ...
Apparantly it was useful to put a bad block at the end of every tape track so
that otherwise sequential data w
On Fri, Jun 24, 2011 at 04:41:44PM +, David Holland wrote:
> On Fri, Jun 24, 2011 at 12:11:22PM +0200, Manuel Bouyer wrote:
> > > I've been thinking that the nfs client problems I've been seeing,
> > > which seem to be callout-related, are maybe connected, as could be the
> > > odd problem m
On Fri, Jun 24, 2011 at 06:37:09PM +0100, David Laight wrote:
> > > > Do we have a debug hook or other method that will raise a panic if
> > > > callouts stop getting processed?
> > >
> > > unfortunably, no (AFAIK).
> >
> > without looking at the code (today) I'm wondering if it would be
>
... this time with a diff attached:
With the attached diff vnd(4) devices will work on sparse files.
- Make the strategy decision a device flag and set to VNF_USE_VN_RDWR for
files known to be sparse.
- Change handle_with_rdwr() to use POSIX_FADV_NOREUSE advise to disable
read ahead.
- Keep the
Hello,
To avoid the race between file descriptor creation and CLOEXEC linux did:
http://udrepper.livejournal.com/20407.html
I have already implemented the open portion and the guts of pipe2() and dup3()
for COMPAT_LINUX, and it is not a lot of work to finish the rest. Should I
finish it?
c
On Fri, Jun 24, 2011 at 10:00:26PM +0200, J. Hannken-Illjes wrote:
> ... this time with a diff attached:
>
> With the attached diff vnd(4) devices will work on sparse files.
> - Make the strategy decision a device flag and set to VNF_USE_VN_RDWR for
> files known to be sparse.
What will the cons
On Fri, Jun 24, 2011 at 04:01:52PM -0400, Christos Zoulas wrote:
> To avoid the race between file descriptor creation and CLOEXEC linux did:
>
> http://udrepper.livejournal.com/20407.html
>
> I have already implemented the open portion and the guts of pipe2() and dup3()
> for COMPAT_LINUX, an
On Fri, Jun 24, 2011 at 04:13:14PM -0400, Thor Lancelot Simon wrote:
> On Fri, Jun 24, 2011 at 10:00:26PM +0200, J. Hannken-Illjes wrote:
> > ... this time with a diff attached:
> >
> > With the attached diff vnd(4) devices will work on sparse files.
> > - Make the strategy decision a device flag
On Fri, Jun 24, 2011 at 12:02:05PM -0400, Thor Lancelot Simon wrote:
> On Fri, Jun 24, 2011 at 07:50:35AM +, Michael van Elst wrote:
> >
> > Similar to raw devices in performance, I/O caching, and without the
> > hardware constraints regarding block sizes or alignment. I.e. something
> > that
>> [...], there's a lot of history behind the notion that userland
>> alignment of write() buffers affects, at most, performance, to the
>> point where I consider it part of the interface.
> Not on access to raw devices it isn't, and never was - what Erik Fair
> said [...] was 100% correct - if you
On Fri, 24 Jun 2011 01:48:56 + (UTC)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> hi,
>
> > I'm now running a more recent kernel (from yesterday morning). This
> > time it hit `"pmap == curpmap" failed: file
> > "/build/src/sys/arch/x86/x86/pmap.c", line 757`
>
> this might be fixed by
24 matches
Mail list logo
