On 03/17/2016 04:16 AM, Andrei Borzenkov wrote:
If there is a way to limit the number of files in a subvolume (aka the btrfs does not limit number of created files by design.
This is one of the things that first attracted me to BtrFS. It is, it should be, a characteristic of a properly done B-tree file system. We saw that with ReiserFS. Carlos reports differently!
Try to create some million files in the same directory (the number depends on the size of the partition). When I did, some time ago, the kernel crashed, and the filesystem corrupted. It was impossible to repair, it needed a format. And before crashing it was going very slow.
The "use cases" of email and nntp are quite valid. Yes, Postfix ameliorates the situation by using hierarchies, but both are relevant in not only ISP settings but in corporate settings. Its not unusual for a corporation ot have many thousands of email addresses. I'd expect the main hubs at companies like IBM, HP and Oracle to be able to deal with millions, because they also have service accounts such as 'sales' and support' and more, as well as redirects and retires. Another use-case to consider is database. Some databases use on big file that contains everything and the DBMS deals with its internal structure, but there are many (MySQL/MariaDB) where these is one file per table and one file per index, and perhaps more. A corporate DB or a ISP that supports many users could have a million tables quite easily. In the spirit of BTDT, yes I've run an ISP and dealt with this. Big OUCH! And yes I've worked at corporations where there were BigData databases where the basic tables ran into the tens of thousands and the temporary tables for applications and more pushed that up by a factor of two to five. Bigger OUCH! Any file system where this a hard boundary between the inode space and the data space can potentially his this problem. huge disks may defer it, but we know full well that they eventually fill up. That's the nature of data! The issue of the boundary between inode space and data space has been around since the early days of UNIX, the V6/7 file system, the Berkeley Fast File System and even the ext4 file system all work that way. Read the man page for mkfs.ext4 and you'll see mention of /etc/mke2fs.conf. It is a way of specifying the inode/data trade off for different types of 'applications", The whole point of ReiserFS is that it avoids this problem. A proper B-tree FS should allocate resources dynamically; I don't understand why ext4FS doesn't. My hope for BtrFS as a replacement for ReiserFS in the absence of Reiser4 was that it would follow in this dynamic nature. Perhaps I should have bought another terabyte disk to devote to it and try the million-file test that Carlos reports. :-( -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org