在 linux/unix 上的 Web 应用程序中为每个文件上传创建一个目录是否有问题？

Question

我正在为一个网络应用程序（在 unix/linux 上运行）进行文件上传。我想知道如果我计划为每个文件上传创建一个新目录是否会出现问题？这是 Ruby on Rails 插件“paperclip”的开箱即用方法。我讨论了如果部署在 linux/unix 环境上的话，权衡是什么，或者是否这不是一个问题。

选项似乎是：

1. 每个文件附件一个文件夹 - 根据回形针开箱即用的方式
2. 每个用户可能有一个文件夹（即如果 Web 服务有多个用户拥有自己的帐户） - 然后需要为文件名添加一些唯一性（可能是模型 ID）
3. 将所有附件放在一个文件夹中 - 但这可能太过分了

问题 - 我应该关心正在创建的目录数量吗？如果服务很受欢迎，这对操作系统来说是一个问题吗？对于允许用户拥有自己的单独帐户上传文件的网站有什么建议，什么结构可能适合存储它们？（我想我已经忽略了在 mysql 中存储文件的概念。）

谢谢

Answer 1

假设Linux下是Ext3格式的驱动器（最常见）。

从 （http://en.wikipedia.org/wiki/Ext3)

“每个目录的子目录数限制为 31998 个，这是由于每个 inode 的链接数限制为 32000 个。[13]”

因此，如果您达到 32k 上传的限制（这个限制并不是那么高），您的应用程序将会失败。

Answer 2

并非如此，但不建议在一个目录中包含无数个文件夹（或文件相同）（这对速度来说是一个真正的打击）。

原因：c 风格字符串

一个好的解决方案是分层（原文如此？）存储类似的内容：/路径/到/用户名第一个字母/用户名/年/月/文件

Answer 3

如果您对创建新文件/目录的目录有一个单独的分区，我会说这不是问题。如果您只使用另一个分区，则可能会出现问题，因为您可能会耗尽索引节点和/或可用磁盘空间，这可能会很糟糕。

使用单独的分区（在 DOS 攻击的情况下）只会阻止您的应用程序正常工作，而系统不会受到任何伤害。