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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101121426.f0CEQll03035>