In most UNIX systems (excluding e.g. Network Appliances and Veritas)
there is a fixed number of inodes defined when you create (mkfs.minx,
newfs, etc.) the file system. The number is configurable within pretty
broad limits. As an aside, recall that every (sub)directory, link, and
file take up an inode. Most folks run into problems resulting from the
amount of email files, but having a lot of empty email users can
therefore cause problems (e.g. when running a free email service).
If I recall, large files can also require multiple inodes. I have
forgotten my vnode to inode mapping rules so I could easily be wrong.
john smith wrote:
>
> Hello. I am creating a qmail-based webmail system(please contact me if
> anyone else is working on this too!) and have some questions about
> Maildirs.
>
> I am concerned with running up against file/inode limits with maildirs.
> However, I have no real knowledge of the underlying file system to base
> this fear on. Can anyone recommend somewhere where I can learn more
> about this? Some of my questions: Does the size of the drive affect the
> maximum number of files? What are the average practical limits?
>
> Also, I would love to hear any general comments on my design for the
> system. I am using Maildirs because the system seems much better in
> most respects that the mail spool files.
Avoids locking problems if multiple deliveries occur in parallel to the
same email.
>
> However, I still sometimes question my choice. Using Maildirs, I simply
> need to scan a directory for files and then put that list up for the
> webmail user to choose from. However, it seems I would have to open
> each file in the dir to get the header info out. I've considered
> updating a central index file as mail arrives but I don't know how well
> that would work.
Watch out for excessive disk io reading/updating the inodes for atime
(in Linix, FreeBSD or Solaris 2.7 you can turn off atime).
>
> I've also considered just inserting all the mails into a mysql database
> when they arrive. Thoughts?
Inserting the HEADERS is a nice speed up but file access will ALWAYS be
faster (30-200%) than ANY database access for a given number of bytes.
>
> Using the traditional spool file sometimes appears to be the best
> option as I can simply open the one file and scan it for headers and
> build a index document with the headers and information regarding what
> byte offset contains each email.
MySQL et al allows you to quickly deliver the headers to the user, e.g.
with JavaScript so the user can sort locally. Going after a given file
then is pretty quick AND stateless.
>
> Well, I don't mean to just pop up on the list and start asking for free
> advice, but if anyone is in the mood to talk, I would love to hear any
> advice or comments.
>
> Thanks,
>
> Jack
>
> _________________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com
--
Daemeon Reiydelle
Systems Engineer, Anthropomorphics Inc.
[EMAIL PROTECTED]
