What's the range of file descriptors on 64-bit Linux?

Question

I'm writing a program using epoll_wait to wait for file descriptors on 64-bit Linux, and I try to put some information together with the file descriptor in the epoll_event user data.

I know in practice it's unlikely that file descriptor will exceed 32 bits. Just wanna know is that kernel guarantees that file descriptors have a specific range, or it just counts from small and unlikely to get very big?

Answer 1

The epoll_ctl(2) interface to add new filedescriptors takes an int fd argument, so you're already limited to 32-bit range (at least on the Linux platforms I'm familiar with).

You're further limited by /proc/sys/fs/file-max system-wide limit on the number of open files for all processes; /proc/sys/fs/file-max is currently 595956 on my system.

Each process is further limited via the setrlimit(2) RLIMIT_NOFILE per-process limit on the number of open files. 1024 is a common RLIMIT_NOFILE limit. (It's very easy to change this limit via /etc/security/limits.conf.)

It's a rare application that needs more than 1024. The full 32 bits seems unlikely as well, since each open file will take some kernel memory to represent -- four billion ~280 byte struct inode structures (at the minimum) is a lot of pinned memory.

Answer 2

Do you plan on having 2 billion file descriptors open, and do you expect the OS to handle this?

In most *nixs, functions that return a FD return it as an int, with < 0 being an invalid descriptor. Those functions return FDs in an int, so that type's range is the range for FDs. (Minus the negatives (no pun intended)) I'd follow suit: use the same type, thus, int.

Answer 3

I found a comment in the kernel indicating the hard upper limit is 1024*1024.