xfs
[Top] [All Lists]

Lots of files

To: <linux-xfs@xxxxxxxxxxx>
Subject: Lots of files
From: "Michel Machado" <michel@xxxxxxxxxxxxxxx>
Date: Thu, 30 Jan 2003 09:57:13 -0200
Organization: Digirati
References: <200301291303.39958.joshhelmer@cox.net>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Hi,

    Book "Postfix", ISBN 0-672-32114-9, page 46, item "Modified active,
bounce, and deferred Queues":

========================
    One item of contention for busy mail servers is the message queues. As
new messages are received, they are placed in separate files in the message
queues. As more files are stores in the message queues, file handling
performance decreases.

    It is a well-known fact on Unix systems that accesing files in a
directory containig lots of files is slower than accessing fewer files in
muitiple subdirectories. Using this information, Venema has modified the
crucial message queue directories (active, bounce, and deferred),
subdividing them into new subdirectories.

    Each of the three main queue directories is split into two levels of
subdirectories. Each message is placed into a subdirectory based on the
first two characters of its filename.

    Figure 2.5 demonstrates this layout:

    /var/spool/postfix/active/
        0/0/
            0023A55F2
            00A3CF9D3
        0/2/
        A/1/
        A/B/
            ABC343CC2
            AB224CD21

    As new messages are received in the message queues, corresponding
subdirectories are created. As files are retrieved from directories, other
message use the subdirectories. Although this structure appears more
complicated, it clearly outperforms the old structure in time required to
retrieve messages from the message queue.
========================

    Is this well-known fact on Unix systems true on XFS? Why? Does the XFS
hash algorithm solve this?

    Is the solution  used by Venema good? Why? On XFS?

    How many files are necessary to produce this effect? 100, 1000, 10000,
100000, 1000000?

    Book on Amazon: http://www.amazon.com/exec/obidos/ASIN/0672321149/

[ ]'s
Michel Machado


<Prev in Thread] Current Thread [Next in Thread>