link() security
Quoted 3 lines · H. Peter Anvin
Not to mention the fact that the single file mailbox design is itself flawed. Mailboxes are fundamentally directories, which news server authors quickly realized.
Funny that news server authors realized that storing messages in files by themselves is a bad idea, while at the same time mail server authors realized that storing messages together in a single file is a bad idea. Which one is right? Both? Neither?
Signature · 3 lines
Chris Adams <[email protected]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Followup to: <[email protected]> By author: Chris Adams <[email protected]> In newsgroup: linux.dev.kernel
Quoted 11 lines
Quoted 3 lines · H. Peter Anvin
Not to mention the fact that the single file mailbox design is itself flawed. Mailboxes are fundamentally directories, which news server authors quickly realized.
Funny that news server authors realized that storing messages in files by themselves is a bad idea, while at the same time mail server authors realized that storing messages together in a single file is a bad idea. Which one is right? Both? Neither?
It depends on your access patterns. Newer news server use what I would classify as custom filesystems (which is what binary databases are, by and large) rather than "single files."
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 9 lines · H. Peter Anvin
Quoted 5 lines
Funny that news server authors realized that storing messages in files by themselves is a bad idea, while at the same time mail server authors realized that storing messages together in a single file is a bad idea. Which one is right? Both? Neither?
It depends on your access patterns. Newer news server use what I would classify as custom filesystems (which is what binary databases are, by and large) rather than "single files."
Exactly. Although I would go farther.
I would not be at all surprised if a traditional news spool worked just fine on a "real" high-performance file system; i.e., one whose lookup/creat/unlink was not linear in the number of directory entries. I wonder how well an old-fashioned news spool would perform on XFS, for instance.
"One file per message" has many advantages, both for news and for mail. The biggest advantage is conceptual simplicity. It is really nice when you can use traditional Unix tools (like grep, mv, rm) to fix things when they break. Because they always break, sooner or later.
Sure, you may wind up with 50,000 files in one directory. But I would rather rely on the filesystem wizards to deal with that than switch to some obscure custom database format. Maybe that's just me...
- Pat
Followup to: <[email protected]> By author: "Patrick J. LoPresti" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 19 lines
Quoted 4 lines
It depends on your access patterns. Newer news server use what I would classify as custom filesystems (which is what binary databases are, by and large) rather than "single files."
Exactly. Although I would go farther.
I would not be at all surprised if a traditional news spool worked just fine on a "real" high-performance file system; i.e., one whose lookup/creat/unlink was not linear in the number of directory entries. I wonder how well an old-fashioned news spool would perform on XFS, for instance.
"One file per message" has many advantages, both for news and for mail. The biggest advantage is conceptual simplicity. It is really nice when you can use traditional Unix tools (like grep, mv, rm) to fix things when they break. Because they always break, sooner or later.
Quoted 4 lines
Sure, you may wind up with 50,000 files in one directory. But I would rather rely on the filesystem wizards to deal with that than switch to some obscure custom database format. Maybe that's just me...
I think the biggest problem with the one-file-per-message format is that you still want to maintain some kind of metadata (.overview files.) This is cached information, but still needs to be maintained, so you don't end up opening up every file to get the overview data. With a application-specific store, you can make that more explicit.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>