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 f
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 an
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 nonblocki
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
> "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
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
> 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 l
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 r
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 hundr
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 th
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 allo
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 minimu
> 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
> "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 apolog
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
21 matches
Mail list logo