在 linux/unix 上的 Web 应用程序中为每个文件上传创建一个目录是否有问题？
我正在为一个网络应用程序（在 unix/linux 上运行）进行文件上传。我想知道如果我计划为每个文件上传创建一个新目录是否会出现问题？这是 Ruby on Rails 插件“paperclip”的开箱即用方法。我讨论了如果部署在 linux/unix 环境上的话，权衡是什么，或者是否这不是一个问题。
选项似乎是：
- 每个文件附件一个文件夹 - 根据回形针似乎开箱即用的方式
- 每个用户可能一个文件夹（即，如果 Web 服务有多个用户拥有自己的帐户） - 然后需要添加一些文件名的唯一性（可能是模型 ID）
- 将所有附件放在一个文件夹中 - 但这可能太过分了
问题 - 我应该关心正在创建的目录数量吗？如果服务很受欢迎，这对操作系统来说是一个问题吗？对于允许用户拥有自己的单独帐户上传文件的网站有什么建议，什么结构可能适合存储它们？ （我想我已经忽略了在 mysql 中存储文件的概念。）
谢谢
I am doing file-upload for a web-application (running on unix/linux). I'm wondering if there would be a concern if I planned to create a new directory for each file upload? This is the out-of-the-box approach for the Ruby on Rails plugin "paperclip". I debating what the trade-offs are, or whether perhaps it's just not a concern, if deploying on a linux/unix environment.
The options would seem to be:
- One folder per file attachment - per how paperclip seems to work out of the box
- One folder per user perhaps (i.e. if web service has multiple users with their own account) - and then one would need to add some uniqueness to the filename (perhaps the model ID)
- Put all attachments in one folder - but this is probably going too far the other way
Question - Should I be concerned about the number of directories being created? Is this an issue for an O/S if the service was popular? Any advice for a website that was allowing users with their own separate account to upload files, what structure might be good with respect to storing them? (I guess I've discounted the concept of storing files in mysql.)
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
假设Linux下是Ext3格式的驱动器（最常见）。
来自（http://en.wikipedia.org/wiki/Ext3）
“有一个限制每个目录有 31998 个子目录，这是由于每个 inode 32000 个链接的限制。[13]”
因此，如果您达到 32k 上传的限制（这个限制并不是那么高），您的应用程序将会失败。
Assuming Ext3 formatted drive under Linux (the most common).
From (http://en.wikipedia.org/wiki/Ext3)
"There is a limit of 31998 sub-directories per one directory, stemming from its limit of 32000 links per inode.[13]"
So, if you'll hit the limit of 32k uploads, which isn't that high, your application will fail.
并非如此，但不建议在一个目录中包含无数个文件夹（或文件相同）（这对速度来说是一个真正的打击）。
原因：c 风格的字符串
一个好的解决方案是分层（原文如此？）存储如下内容：
/路径/到/用户名第一个字母/用户名/年/月/文件
Not as such, but having gazillions of folders in one directory (or the same for files) isn't recommended (it's a real hit to speed).
Reason: c-style strings
A good solution would be to hierchially (sic?) store things something like:
/path/to/usernamefirstletter/username/year/month/file
如果您对创建新文件/目录的目录有一个单独的分区，我会说这不是问题。如果您只使用另一个分区，则可能会出现问题，因为您可能会耗尽索引节点和/或可用磁盘空间，这可能会很糟糕。
使用单独的分区（在 DOS 攻击的情况下）只会阻止您的应用程序正常工作，而系统不会受到任何伤害。
If you have a separate partition for the directory where the new files/directories get created, I'd say it's not a problem. It can get a problem if you just use another partition since you can run out of inodes and/or free disk space which can be bad.
Using a separate partition would (in case of a DOS attack) only stop your application from working correctly and the system won't get hurt in any way.