In terms of the web server the file system is largely irrelevant. When it comes to source code you should be using an opcode cache (the open source Zend one now available in 5.5 is a great option). This should cause PHP to not touch the file system at all once the cache is warm. And even so, the disk block cache in the Linux kernel renders most read performance differences between file systems to be rendered relatively moot. Some have recommended using tmpfs for deployment but this gives you almost no benefit and may actually be a little slower.
One place where one might think that you could get a boost would be on writes to the file system, such as caching or sessions. However, I would contend that if you were running your web server so hot that you had high write IO wait time on your web server then you should not be on one server any more and start moving that stuff to Redis. You should only see a slowdown if there are many, many thousands of files stored in the /var/session or /var/cache directories where writes are required to scan the inode index to find a free disk block. But the likelihood of you reaching that level on one server is quite unlikely.
But while the webserver is largely unimportant, the database server can be immensely important. Basically, don't use ext3. XFS is preferred by most (if not all) MySQL admins, but if you are on ext4 I wouldn't tell you to move. The problem goes back to how ext3 allocates disk blocks via an indirect bitmap whereas ext4/XFS uses extents. I don't know exactly how extents work (I am a web developer, after all) but I understand that they are more along the lines of a true index rather than a simple indirect bit-mapping of disk blocks.
So, web server: meh. DB: XFS or ext4.