Take a look at this list http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_fault-tolerant_file_systems
and which is the best choice for storing large number of static media files (with normal file size: 10KB-2M for images, and 5M-500M for video files) of a website? (among these distributed parallel fault tolerant file systems)
Sorry to give a non-answer, but what you're asking raises an eyebrow. If you really need a clustered file system, I would expect some kind of explanation as to why.
Answer: None of the above -- go with a "filesystem" that isn't a POSIX compliant file system, but rather a HTTP service oriented towards file storage, replication and redundancy. Examples include MogileFS (self-hosted, originally created by Brad Fitzpatrick) or Amazon Simple Storage Service (hosted service), or Windows Azure's blobs (.NET, hosted service).
Based on your previous questions you appear to be just starting out, i.e. greenfield development. If so, then generally speaking you're better off purchasing file storage as a service at market price, rather than trying to build something yourself. Getting availability and replication right on a large scale is hard.
I agree with Jesper on this one, personally I'd use a pair of Zeus ZXTM's as coherent caches in front of a pair of standard http servers serving from a single shared NFS/CIFS mount.
That said if you want to do it like this I've had a lot of good experiences with Ibrix myself.
GlusterFS has a very good reputation, but may be overkill for your application. Have you considered distributing the files on server pairs, e.g.
2 ips for static1.yourdomain.com 2 ips for static2.yourdomain.com ...
Always two servers for redundancy. Should any static group get too much traffic, add more servers to that group for scaling.