I apologize for bringing this to the list, but after several hours of
google, testing, and so forth I'm coming up blank. I've been unable
to reproduce this state in targeted tests, however the application
itself does it on a semi-regular basis.
I currently have an application with the following s
I couldn't edge-trigger disk IO through
poll().
Thoughts, comments?
-Aaron
On 6/4/07, Aaron Wiebe <[EMAIL PROTECTED]> wrote:
On 6/4/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> So exactly how would you expect a nonblocking open to work? Should it be
> starti
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.
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 pathna
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
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
d
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 cache-cohere
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 allo
a nonblocking flag return EAGAIN if its going to take
anywhere near 415ms? Is there a way I can force opens to EAGAIN if
they take more than 10ms?
Thanks for any help you folks can offer.
-Aaron Wiebe
(ps. having come from the socket side of the fence, its incredibly
frustrating to
Greetings,
I've run into a situation where fcntl F_SETLKW calls lock up nearly
completely. I've tried several approaches to handle this case, and
have yet to come up with some method of handling this. I've never
really ventured outside userspace, so I'm turning to this list to try
and get a han
Greetings,
I've run into a situation where fcntl F_SETLKW calls lock up nearly
completely. I've tried several approaches to handle this case, and
have yet to come up with some method of handling this. I've never
really ventured outside userspace, so I'm turning to this list to try
and get a han
12 matches
Mail list logo
