Aaron Wiebe wrote:
> David Schwartz wrote:
> > There is no way you can re-try the request. The open must
> > either succeed or
> > not return a handle. It is not like a 'read' operation that has
> > an "I didn't
> > do anything, and you can retry this request" option.
> > If 'open' returns a
On Mon, 2007-06-04 at 12:26 -0400, Aaron Wiebe wrote:
> Actually, lets see if I can summarize this more generically... I
> realize I'm suggesting something that probably would be a massive
> undertaking, but ..
>
> Regular files are the only interface that requires an application to
> wait. With
Actually, lets see if I can summarize this more generically... I
realize I'm suggesting something that probably would be a massive
undertaking, but ..
Regular files are the only interface that requires an application to
wait. With any other case, the nonblocking interfaces are fairly
complete
On 6/4/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
So exactly how would you expect a nonblocking open to work? Should it be
starting I/O? What if that involves blocking? How would you know when to
try again?
Well, theres a bunch of options - some have been suggested in the
thread already.
On Mon, 2007-06-04 at 10:20 -0400, Aaron Wiebe wrote:
> I understand, but this is exactly the situation that I'm complaining
> about. There is no functionality to provide a nonblocking open - no
> ability to come back around and retry a given open call.
So exactly how would you expect a
Sorry for the unthreaded responses, I wasn't cc'd here, so I'm
replying to these based on mailing list archives
Al Viro wrote:
BTW, why close these suckers all the time? It's not that kernel would
be unable to hold thousands of open descriptors for your process...
Hash descriptors by
On 6/4/07, John Stoffel <[EMAIL PROTECTED]> wrote:
So how many files are in the directory where you're seeing the delays?
And what's the average size of the files in there?
The directories themselves will have a maximum of 160 files, and the
files are maybe a few megs each - the delays are
Replying to David Schwartz here.. (David, good to hear from you again
- haven't seen you around since the irc days :))
David Schwartz wrote:
There is no way you can re-try the request. The open must either succeed or
not return a handle. It is not like a 'read' operation that has an "I didn't
> "Aaron" == Aaron Wiebe <[EMAIL PROTECTED]> writes:
Aaron> On 6/4/07, Alan Cox <[EMAIL PROTECTED]> wrote:
>>
>> > Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
>> > call with a nonblocking flag return EAGAIN if its going to take
>> > anywhere near 415ms?
>>
>>
On 6/4/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
> call with a nonblocking flag return EAGAIN if its going to take
> anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
On 6/3/07, Neil Brown <[EMAIL PROTECTED]> wrote:
Have you tried the "nocto" mount option for your NFS filesystems.
The cache-coherency rules of NFS require the client to check with the
server at each open. If you are the sole client on this filesystem,
then you don't need the same
> Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
> call with a nonblocking flag return EAGAIN if its going to take
> anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
Alan
-
To unsubscribe from this list: send the
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag return EAGAIN if its going to take
anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
Alan
-
To unsubscribe from this list: send the
On 6/3/07, Neil Brown [EMAIL PROTECTED] wrote:
Have you tried the nocto mount option for your NFS filesystems.
The cache-coherency rules of NFS require the client to check with the
server at each open. If you are the sole client on this filesystem,
then you don't need the same
On 6/4/07, Alan Cox [EMAIL PROTECTED] wrote:
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag return EAGAIN if its going to take
anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
Aaron == Aaron Wiebe [EMAIL PROTECTED] writes:
Aaron On 6/4/07, Alan Cox [EMAIL PROTECTED] wrote:
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag return EAGAIN if its going to take
anywhere near 415ms?
Violation of causality. We don't
Replying to David Schwartz here.. (David, good to hear from you again
- haven't seen you around since the irc days :))
David Schwartz wrote:
There is no way you can re-try the request. The open must either succeed or
not return a handle. It is not like a 'read' operation that has an I didn't
On 6/4/07, John Stoffel [EMAIL PROTECTED] wrote:
So how many files are in the directory where you're seeing the delays?
And what's the average size of the files in there?
The directories themselves will have a maximum of 160 files, and the
files are maybe a few megs each - the delays are (as
Sorry for the unthreaded responses, I wasn't cc'd here, so I'm
replying to these based on mailing list archives
Al Viro wrote:
BTW, why close these suckers all the time? It's not that kernel would
be unable to hold thousands of open descriptors for your process...
Hash descriptors by
On Mon, 2007-06-04 at 10:20 -0400, Aaron Wiebe wrote:
I understand, but this is exactly the situation that I'm complaining
about. There is no functionality to provide a nonblocking open - no
ability to come back around and retry a given open call.
So exactly how would you expect a nonblocking
On 6/4/07, Trond Myklebust [EMAIL PROTECTED] wrote:
So exactly how would you expect a nonblocking open to work? Should it be
starting I/O? What if that involves blocking? How would you know when to
try again?
Well, theres a bunch of options - some have been suggested in the
thread already.
Actually, lets see if I can summarize this more generically... I
realize I'm suggesting something that probably would be a massive
undertaking, but ..
Regular files are the only interface that requires an application to
wait. With any other case, the nonblocking interfaces are fairly
complete
On Mon, 2007-06-04 at 12:26 -0400, Aaron Wiebe wrote:
Actually, lets see if I can summarize this more generically... I
realize I'm suggesting something that probably would be a massive
undertaking, but ..
Regular files are the only interface that requires an application to
wait. With any
Aaron Wiebe wrote:
David Schwartz wrote:
There is no way you can re-try the request. The open must
either succeed or
not return a handle. It is not like a 'read' operation that has
an I didn't
do anything, and you can retry this request option.
If 'open' returns a file handle,
David Schwartz writes:
[Aaron Wiebe]
open("/somefile", O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 <0.415147>
How could they make any difference? I can't think of any
conceivable way they could.
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag
In article <[EMAIL PROTECTED]> you wrote:
> In short, I'm distributing logs in realtime for about 600,000
> websites. The sources of the logs (http, ftp, realmedia, etc) are
> flexible, however the base framework was build around a large cluster
> of webservers. The output can be to several
On Sunday June 3, [EMAIL PROTECTED] wrote:
>
> You can certainly open the file, but not block on the call to do it.
> What confuses me is why the kernel would "block" for 415ms on an open
> call. Thats an eternity to suspend a process that has to distribute
> data such as this.
Have you tried
In article <[EMAIL PROTECTED]> you wrote:
> (ps. having come from the socket side of the fence, its incredibly
> frustrating to be unable to poll() or epoll regular file FDs --
> Especially knowing that the kernel is translating them into a TCP
> socket to do NFS anyway. Please add regular files
Hi John, thanks for responding. I'm using kernel 2.6.20 on a
home-grown distro.
I've responded to a few specific points inline - but as a whole,
Davide directed me to work that is being done specifically to address
these issues in the kernel, as well as a userspace implementation that
would
On Sun, Jun 03, 2007 at 05:27:06PM -0700, David Schwartz wrote:
>
> > Now, Netapp speed aside, O_NONBLOCK and O_DIRECT seem to make zero
> > difference to my open times. Example:
> >
> > open("/somefile", O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 <0.415147>
> The 'open' function must, at
> Now, Netapp speed aside, O_NONBLOCK and O_DIRECT seem to make zero
> difference to my open times. Example:
>
> open("/somefile", O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 <0.415147>
How could they make any difference? I can't think of any conceivable way
they could.
> Now, I'm a userspace
> "Aaron" == Aaron Wiebe <[EMAIL PROTECTED]> writes:
More details on which kernel you're using and which distro would be
helpful. Also, more details on your App and reasons why you're
writing bunches of small files would help as well.
Aaron> Greetings all. I'm not on this list, so I
On Sun, 3 Jun 2007, Aaron Wiebe wrote:
> (ps. having come from the socket side of the fence, its incredibly
> frustrating to be unable to poll() or epoll regular file FDs --
> Especially knowing that the kernel is translating them into a TCP
> socket to do NFS anyway. Please add regular files
On Sun, 3 Jun 2007, Aaron Wiebe wrote:
(ps. having come from the socket side of the fence, its incredibly
frustrating to be unable to poll() or epoll regular file FDs --
Especially knowing that the kernel is translating them into a TCP
socket to do NFS anyway. Please add regular files to
Aaron == Aaron Wiebe [EMAIL PROTECTED] writes:
More details on which kernel you're using and which distro would be
helpful. Also, more details on your App and reasons why you're
writing bunches of small files would help as well.
Aaron Greetings all. I'm not on this list, so I apologize if
Now, Netapp speed aside, O_NONBLOCK and O_DIRECT seem to make zero
difference to my open times. Example:
open(/somefile, O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 0.415147
How could they make any difference? I can't think of any conceivable way
they could.
Now, I'm a userspace guy so I
On Sun, Jun 03, 2007 at 05:27:06PM -0700, David Schwartz wrote:
Now, Netapp speed aside, O_NONBLOCK and O_DIRECT seem to make zero
difference to my open times. Example:
open(/somefile, O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 0.415147
The 'open' function must, at minimum, confirm
Hi John, thanks for responding. I'm using kernel 2.6.20 on a
home-grown distro.
I've responded to a few specific points inline - but as a whole,
Davide directed me to work that is being done specifically to address
these issues in the kernel, as well as a userspace implementation that
would
In article [EMAIL PROTECTED] you wrote:
(ps. having come from the socket side of the fence, its incredibly
frustrating to be unable to poll() or epoll regular file FDs --
Especially knowing that the kernel is translating them into a TCP
socket to do NFS anyway. Please add regular files to
On Sunday June 3, [EMAIL PROTECTED] wrote:
You can certainly open the file, but not block on the call to do it.
What confuses me is why the kernel would block for 415ms on an open
call. Thats an eternity to suspend a process that has to distribute
data such as this.
Have you tried the
In article [EMAIL PROTECTED] you wrote:
In short, I'm distributing logs in realtime for about 600,000
websites. The sources of the logs (http, ftp, realmedia, etc) are
flexible, however the base framework was build around a large cluster
of webservers. The output can be to several hundred
David Schwartz writes:
[Aaron Wiebe]
open(/somefile, O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 0.415147
How could they make any difference? I can't think of any
conceivable way they could.
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag
42 matches
Mail list logo
