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 <j...@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<j...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
