Non-blocking file access?

Question

1. Did I miss something: is there a way in java 1.5 (or even java 1.6) to read files and query file metadata (size, last modified, that kind of thing) in a non-blocking manner?
2. Is there a way to figure out where physical harddrive boundaries lie without resorting to tricks like running 'df' and parsing the output, which is rather un-portable? I obviously don't want to create a thread per file read (one aim is that the maximum number of threads is constant - even with a gazillion requests the amount of threads will never exceed a (low) constant.) but just 1 thread to perform all required reads would possibly end up wasting time if there are multiple harddrives and the CPU is idling anyway. I'd guess at this point that 1 thread per physical harddrive handling all file access is the best way to go, but how do I figure out those boundaries?
3. Is NIO2 (JSR 203) going to add features to work with files in a non-blocking way?
4. Is there a full-stack (templating, database access, writing web services, serving up the data) web server out there someplace that works entirely on a non-blocking methodology? I don't think so, but I might have missed something. JETTY tries something, but the servlet specs fundamentally do not work with non-blocking I/O, so it doesn't count.
background:
I'm writing a non-blocking webserver. KISS is the attitude - so far the basic system and any services (my take on the servlet spec, as the servlet spec doesn't play nice with NIO principles) on it all run inside a single thread, no thread pool.
So far it all works, and stress testing it with 1000 connections, 200 at the same time shows a process time of about half a millisecond per request, on a simple macbook, which is nice, because that beats apache even at serving up 404s.
So far I have only written very simple test apps that for example do calculations and the like, nothing that you'd actually do with web apps, like, say, serving (template-powered) data from files on a harddrive.
Because of the absolute requirement for each service NEVER to block while serving up bytes, manually working with files would be an unbelievable pain on the part of the web service developer. Hence I'm building templating and DB access into the system.
Unfortunately, I realized, reading NIO specs, that there doesn't seem to be any way to perform file operations in a non-blocking manner (not just reading them, but getting file size and last modified timestamps as well). I'll obviously have to use a lot of caching tactics, but before I can cache, I need to read files somehow.
The aim of this webserver is basically to survive massive spikes in traffic, be it from digg/slashdot, or from a DDOS attack, as best as possible, and where that isn't possible, to gracefully fall apart. That is, service as many requests as possible at a certain minimum bandwidth per request, prioritizing repeat visitors and site moderators, and deny the rest instantly, instead of just falling apart in shambles as happends in your usual LAMP or servlet design, not serving even 1 request right most of the time.
Thanks a lot for everyone's time!

Answer 1

ejp wrote:
BufferedInputStream will improve the performance by a factor of several thousand because it cuts down on system calls.Well, that might be true if you're reading individual bytes with a call to read(), or making many small read( buffer ) requests. But if you call read( buffer ) with a reasonably sized buffer (BufferedInputStream uses 8192 bytes as a default buffer size), then you're going to get performance equal to or possibly better than a BufferedInputStream.