Initial conclusions is that XFS and JFS are both waaaay better than EXT3 or ReiserFS for a video partition. In fact, I would dare say that even ReiserFS is even better than EXT3 for a video partition.

There were a number of strange trends in the returned results.

1. On EXT3, deleting files took longer per Gigabyte the larger the file was. A 1GB file took 0.885 seconds to delete, so you might expect n 8GB file to take 7 seconds to delete, but instead it took around 10.4 seconds.
2. On ReiserFS, writing a 1GB and 4GB file took about 25 seconds per Gigabyte. But writing a 2GB and 8GB file took about 20 seconds per Gigabyte. These numbers were consistent across all three test runs.
3. On ReiserFS, delete times for the 4GB files ranged wildly with 1.2, 2.4, and 3.0 seconds. Times on other files indicate 1.2 as the most probable score. Normalized to 1.2 would have dropped the average delete time by 20%. All other scores were fairly consistent across runs.
4. On JFS, 8 out of 12 delete times were 0.012 seconds, which are all impossible.
5. File size did not seem to impact delete speed for XFS or JFS, but increased time for EXT3 and REiserFS.

Just a couple suggestions. FS speed tests usually include a CPU usage measurement for each of the operations. A FS that does the operation in half the time is great but if it does so at the cost of pegging the CPU that's less desirable. You may also want to test concurrent operations, deleting multiple files at the same time or deleting while reading/writing.

Finally you may want to look at other features. I've stuck with EXT3 on my /myth partition for the simple reason that it can be resized. I'm pretty sure this applies to the IBM JFS too, but I _know_ that it does for EXT3.

BTW - Your well on your way to a really well done Linux FS review. Congrats and Happy New Year!

I'm not fully versed on Linux FS' but I have always used XFS until the most recent install where I used JFS. while you say it's not possible to delete a 8 gig file in 12ms, I would say, 9ms to seek, 3ms to set a "deleted" bit to a 1, or to even remove then entry from the journal's table (like a File Allocation Table, effectively removing it's existance from the FS). You don't really ever need to overwrite the data, or even reset the data section. If it doesn't know it's there it will simply overwrite the data on the next pass.

Reiser and EXT3 seem to behave like a library, you can't just remove the reference to the book, you must remove the book aswell, which involves the time to look for it, and pull it from the shelf. XFS and JFS operate more like an overwritable media should. Remove the card, forget it's there. next book you need to put in, just stick it in the spot and let the old book fall into the abyss behind the shelf.

This also makes JFS and XFS bad candidates for secure files where you would want to delete the physical information so it can't be recovered.

_________________
AthlonXP 2500/768Mb DDR
AbitNF7 (onboard Audio),Geforce 5200
NFS share for 1.5tb (3 x 500Gb) w/ XFS under FC7.
ATI HDTv Wonder, Hauppauge 150MCE
ThermalTake Bach case

How do I record CPU usage? Other than running 'top' in a terminal, I'm not really sure how to do that. Is there any fancy tool that might show and record as a graph?

How do I test concurrent reads/writes? Is there a way in bash to say to start two operations at once?

Honestly I think that most playback problems when deleting files could be solved with more aggressive read-ahead caching in the player. But excepting that, I guess just picking a better FS would be the best solution.

My comment about JFS's delete times was more at issue with physical impossibilities. A fast 7200 RPM IDE drive will have a typical average write seek time of 12-14ms. 3ms might be possible, but it isn't likely to happen often. My drive should be giving something in the line of 14-24ms, so from the numbers something is obviously being fudged. Still, it might not even matter if the difference is small enough.

Is one way to do it. You'd have to collect and correlate the data with you FS timings.

You can get pretty close with something like:

The OS will let you run many, many thing things at once after all. I'd probably roll a little Python framework that played fork/exec/wait games so I could time each process.

Okay, I took the easy way out on this. Because the time command lists real/user/sys times, I just used the times already provided in my previous results. Here are some quick graphs to display System time used. Note that the graphs are not on 0-100% scale.

Writing:


Reading:


Deleting:



In these results, JFS is the clear winner, while XFS is the runner up. XFS may show high delete CPU usage, but recall that delete times for XFS were less than 0.05 seconds, or less than 2 frames for 30 fps video. Even if it prevented decoding video, you would skip at max 1-2 frames.

Updated source spreadsheet can be gotten here.

* I ignored User times for almost all results as except for JFS delete times, all user times were less than 1% the value of the System time. For JFS I added the User and System times together as the System time values sometimes had a value of zero.

I do wish I could test simultaneous read/writes/deletes, but I haven't figured out a way to do it and produce meaningful results. I'm guessing someone else will tackle this when the mood strikes them.

Another set of generic benchmarks here:

http://linuxgazette.net/102/piszcz.html


Note that they aren't specific to PVR tasks. But they will give you an idea of what each filesystem excels at.

The reason JFS is so good for PVR systems is that:

- you don't care too much about read/write speed for large files, since you're reading / writing them rather slowly most of the time.

- you want deletes to be as fast as possible.

- you rarely deal with lots of small files or lots of small directories.