You might be interested in this whitepaper from Intel. What they find is that the Windows CIFS client write pattern creates serious fragmentation problems for ext3. The problems are mitigated (though probably not completely solved) in XFS precisely by what you mention - delayed allocation.

The infamous XFS binary NULLs problem was fixed in 2007.

It *was* a problem, despite the XFS developers saying before 2007 exactly what the ext4 developers are saying now: "We're following spec, so it's your problem if you lose data."

Sooner or later, ext4 will be fixed, just like XFS was, once the developers realize that "omg my data is gone" is filesystem publicity death, no matter how on-spec they are.

In fairness to XFS, they finally accepted that binary NULLs were a problem and fixed it in the spring of 2007.

Yeah, I was always too lazy to do that. :-) I figure the Python developers should to it for me in C. (I'd want to benchmark a solution like that, too. How does it do with millions of files?)

Your idea works until you have a huge number of files (not uncommon for a backup script) and run out of memory on the .read() call. Not pretty. To avoid that, you have to use .readline() or the file iterator, both of which have the newline limitation I mentioned.

I've run into one big problem replacing find/xargs in Python: There's no good equivalent of the find '-print0' and xargs '-0' options. Efficient iteration over stdin (or file) lines in Python can *only* use the regular line separator. If you want to write a backup script that uses find instead of os.walk for speed and pump it into Python for convenience, everything breaks as soon as you hit a filename with a newline in it.

(And no, trying to enforce a "no newlines in filenames" policy doesn't work. Been there, tried that.)

We are going to have two layers, but they'll be deeper in the filesystem than that.

High frequency, low volume operations - metadata journalling, certain database transactions - will go to flash, and low frequency, high volume operations - file transfers, bulk data moves - will go to regular hard drives. SSDs aren't yet all that much faster for bulk data moving, so it makes the most economic sense to put them where they're most needed: Where the IOPs are.

Back in the day, a single high-performance SCSI drive would sometimes play the same role for a big, cheap, slow array. Then, as now, you'd pay the premium price for the smallest amount of high-IOPs storage that you could get away with.