llnl / llnl/Silo

Set Silo's DB_NFILES compile-time parameter at runtime

Open
#88 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
45
Forks
27
Avg merge
12h 34m
Merged PRs (30d)
4

Description

Brian Rujiuz and Matt O'Brian requested this. Currently, Silo places an upper limit on maximum number of concurrently opened files. That number is 256 and it is set at compile time. First, I have no idea why 256 was chosen. It could be a value that was appropriate for machines that existed when Silo was first being written about 20 years ago. Most systems place an upper limit on total number of open files (descriptors) at 1024 or above. We can't get around that limit. But, Silo could be modified to use whatever the system limit as its own internal limit instead of a hard-coded 256.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 646
Status: New
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Set Silo's DB_NFILES compile-time parameter at runtime
Assigned to: -
Category: -
Target version: -
Author: Mark Miller
Start: 03/08/2011
Due date:
% Done: 0%
Estimated time: 4.00 hours
Created: 03/08/2011 06:52 pm
Updated:
Likelihood:
Severity:
Found in version:
Impact: 2 - Low
Expected Use: 2 - Rare
OS: All
Support Group: Any
Description:
Brian Rujiuz and Matt O'Brian requested this. Currently, Silo places an upper limit on maximum number of concurrently opened files. That number is 256 and it is set at compile time. First, I have no idea why 256 was chosen. It could be a value that was appropriate for machines that existed when Silo was first being written about 20 years ago. Most systems place an upper limit on total number of open files (descriptors) at 1024 or above. We can't get around that limit. But, Silo could be modified to use whatever the system limit as its own internal limit instead of a hard-coded 256.

Comments:

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Search the source for the DB_NFILES compile-time parameter and the code that enforces the concurrent open-file limit. Check how the system's file-descriptor limit can be obtained across supported systems, then verify that Silo uses that limit instead of the hard-coded 256 without exceeding the operating-system maximum.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
databases
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.