From: Jim <jim@webstarts.com>
To: Ken D'Ambrosio <ken@jots.org>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: too many files open
Date: Wed, 05 Oct 2011 12:15:05 -0400 [thread overview]
Message-ID: <4E8C8289.6050100@webstarts.com> (raw)
In-Reply-To: <5dc5c2e75fcd85e5da1ae83fcc7eba05@www.jots.org>
Ken,
That was a great $.02, more like a nickle. max files are 3255380 but
file handles are 0. Current files are 832.
I am unfamiliar with how this part of the fs works so how can I increase
file handles?
Thanks
Jim
On 10/05/2011 12:07 PM, Ken D'Ambrosio wrote:
> Well, I hate to grasp for a flyswatter when a hammer might be better, but
> what's /proc/sys/fs/file-nr show? The first number is your currently opened
> files, the last one is your maximum files (as dictated by
> /proc/sys/fs/file-max), and the middle one's allocated-but-unused file handles.
> If it's showing a number anything near your max files, it's probably a fine
> time to check out lsof. Looking for where the disparity lies will probably
> offer some insights, I imagine.
>
> $.02,
>
> -Ken
>
>
> On Wed, 05 Oct 2011 11:54:35 -0400 Jim<jim@webstarts.com> wrote
>
>> Checked ulimit and processes are not the issue here. Rsync never has
>> more than 15 instances running and even accounting for children and
>> other processes they wouldnt approach the process limit. The error
>> ddoes seem to be with btrfs as I cant ls the file system while this
>> condition exists. Ls also returns "too many files open". Btrfs sub
>> list also shows the same too many files open condition. Actually, there
>> should be no files open after the script has failed (the script runs,
>> just reports the errors). Something either reports files as being open
>> or is holding them open, and a remount flushes this and the fs is back
>> to normal. Very confusing.
>> Jim
>>
>> On 10/05/2011 11:32 AM, Jim wrote:
>>> Thanks very much for the idea. I will check and get back.
>>> Jim
>>>
>>>
>>> On 10/05/2011 11:31 AM, Roman Mamedov wrote:
>>>> On Wed, 05 Oct 2011 11:24:27 -0400
>>>> Jim<jim@webstarts.com> wrote:
>>>>
>>>>> Good morning Btrfs list,
>>>>> I have been loading a btrfs file system via a script rsyncing data
>>>>> files
>>>>> from an nfs mounted directory. The script runs well but after several
>>>>> days (moving about 10TB) rsync reports that it is sending the file list
>>>>> but stops moving data because btrfs balks saying too many files
>>>>> open. A
>>>>> simple umount/mount fixes the problem. What am I flushing when I
>>>>> remount that would affect this, and is there a way to do this without a
>>>>> remount. Once again thanks for any assistance.
>>>> Are you sure it's a btrfs problem? Check "ulimit -n", see "help
>>>> ulimit" (assuming you use bash).
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
next prev parent reply other threads:[~2011-10-05 16:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 15:24 too many files open Jim
2011-10-05 15:31 ` Roman Mamedov
[not found] ` <4E8C7885.50205@webstarts.com>
2011-10-05 15:54 ` Jim
2011-10-05 16:07 ` Ken D'Ambrosio
2011-10-05 16:15 ` Jim [this message]
2011-10-05 17:18 ` Jim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E8C8289.6050100@webstarts.com \
--to=jim@webstarts.com \
--cc=ken@jots.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.