linux-kernel - Re: slow open() calls and o

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070604010544.GX4095@ftp.linux.org.uk>
Date:	Mon, 4 Jun 2007 02:05:44 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	David Schwartz <davids@...master.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: slow open() calls and o_nonblock

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 that the file exists (or
> doesn't exist and can be created, or whatever). This takes however long it
> takes on NFS.
> 
> You need either threads or a working asynchronous system call interface.
> Short of that, you need your own NFS client code.

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 pathname and be done with that; don't bother with
close unless you decide that you've got too many of them (e.g. when you
get a hash conflict).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/