Date: Fri, 12 Jan 2001 09:26:47 -0500 From: "Brian J. McGovern" <bmcgover@cisco.com> To: Chris Peiffer <chris@redlinenetworks.com> Cc: hackers@freebsd.org Subject: Re: Question about 'open' files.... Message-ID: <200101121426.f0CEQll03035@bmcgover-pc.cisco.com> In-Reply-To: Your message of "Thu, 11 Jan 2001 14:42:22 PST." <20010111144222.A31382@redlinenetworks.com>
index | next in thread | previous in thread | raw e-mail
Actually, I finally found it. One of the function calls I pulled from a
library someone else wrote used mkstemps(), and didn't bother to discard the
descriptor when it was done.
I had originally thought the problem to be in my code, but, it wasn't. I fixed
the other code, and the problem was solved.
-Brian
>
> Don't know if this is part of the error checking you glossed over,
> but I recently had some extremely weird problems with file IO that went away
> when I added the third mode argument that open() needs when it is passed the
> O_CREAT flag.
>
>
> On Thu, Jan 11, 2001 at 03:05:29PM -0500, Brian J. McGovern wrote:
> > I'm doing some tests for Greg on vinum (trying to crash it), and I've run
> > across a problem that is not particular to vinum. I'm hoping someone can
> > explain it to me and/or tell me how to work around it.
> >
> > Using the code fragment (note: The code I'm using is actually more complex
,
> > and checks for errors in opening, writing, etc, but I'm keeping it basic
> > for the discussion):
> >
> > for (counter = 0; counter < 20000; counter++)
> > {
> > x = open(filename,O_CREAT | O_WRONLY);
> > write(x, buffer, size);
> > close(x);
> > }
> >
> >
> > I will run anywhere between 1-5 instances of the code loop above. After th
ere
> > are about 2050 files on the disk (it _appears_ to be variations of 2048, p
lus
> > files already on the disk, . and .., etc.), the programs crash with "too m
any
> > open files".
> >
> > The problem, in my mind, is that the files are _closed_ (not open). I'm cu
rious
> if this is some type of accounting error on a per-login basis, or whether
> > there is some type of garbage collection not happening. Typically, after a
ll
> > of the applications die with this error, if I immediately restart, they
> > die pretty quickly. If I wait like 10+ seconds, they can run again, and
> > generate the 2048+/- files again before dying, which leads me to believe i
ts
> > something to do with per-user accounting/garbage collection.
> >
> > I would be curious to understand this, and its impact, as this does not
> > appear to be 'good' (tm) behavior, particularly if one wishes to run a pro
gram
> > that opens and closes a lot of small files.
> >
> > I welcome any thoughts.
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101121426.f0CEQll03035>