64位Linux系统文件描述符的范围是多少？

Question

我正在编写一个程序，使用epoll_wait在64位Linux上等待文件描述符，并尝试将一些信息与epoll_event用户数据一起放置。

我知道实际上文件描述符不太可能超过32位。只是想知道内核是否保证文件描述符具有特定的范围，还是仅从小计数并且不太可能变得非常大？

- Ralph Zhang

---

我想FD号码是循环利用的——例如，永远不会超过进程的并发打开描述符的最高数量——但是......我一点也不清楚。 - user166390

fd的定义是“小”的非负整数，无论在运行时“小”意味着什么。除此之外，内核不保证它的值。 - Pete Wilson

Answer 1

epoll_ctl(2)接口添加新的文件描述符需要一个int fd参数，因此在我熟悉的Linux平台上，您已经受到32位范围的限制。

您还受到/proc/sys/fs/file-max系统范围内对所有进程打开的文件数的限制；/proc/sys/fs/file-max当前在我的系统上为595956。

每个进程还受到setrlimit(2)RLIMIT_NOFILE每个进程对打开文件数量的限制。1024是常见的RLIMIT_NOFILE限制。 （可以通过/etc/security/limits.conf轻松更改此限制。）

很少有应用程序需要超过1024. 似乎也不太可能使用全部32位，因为每个打开的文件都将占用一些内核内存来表示 - 四十亿个280字节的struct inode结构（至少）占用了大量锁定内存。

- sarnold

---

谢谢，看起来我可以安全地节省一些位来使用。 - Ralph Zhang

Answer 2

你是否计划打开20亿个文件描述符，并且希望操作系统处理这些呢？

在大多数*nix中，返回FD的函数将其作为int返回，其中< 0是无效描述符。这些函数使用int返回FD，因此该类型的范围是FD的范围。(减去负数(无恶意))。我建议遵循相同的做法：使用相同的类型，即int。

- Thanatos

Answer 3

我在内核中找到了一条评论，指出硬上限为1024*1024。

- Joshua

Answer 4

64位（也适用于32位系统）Linux上的文件描述符范围是0到1023，您不能创建超过1023个打开的文件描述符。如果您尝试打开超过1023个文件描述符，则系统将返回错误EBADF（坏文件描述符），错误编号为-9。

- premal

---

来源/引用？ - undefined