While generic test comparison results may be useful as a "rough guide", it's important to remember that no matter which performance test result you may see, it's not representative of your workload for your data on your server hardware (and even more specifically for filesystems, on your media device).

Hence, the most accurate answer is to compare the filesystem timings for yourself on a representative performance test.

From: http://sqlanywhere-forum.sap.com/questions/12501/how-to-size-a-machine-for-sqlanywhere-with-1000-connections/12512

To best determine your hardware information you have to create a performance test that mimics your production workload. This performance test should control as many different performance factors in the database server as possible, while modifying an individual server factor in a set of tests to establish its effects on your overall throughput. Once you have gathered this information (after varying things like the server cache size, number of worker threads, optimal levels of intra-query parallelism, etc.) you can then use statistical analysis to figure out which performance factors are the most important for your workload.

Considerations for constructing a performance test: http://www.sybase.com/detail?id=1056535

Server performance considerations in SQL Anywhere: http://www.sybase.com/files/White_Papers/wp_ias_diagnosing_app_perf.pdf

For the filesystem comparison case, you want to hold all other performance factors constant (e.g. ensure you start with the same database and static cache options) and only change the file system that the test database is hosted on.

Here's a comparison of Linux filesystem performance from June 2012: BTRFS vs EXT3 vs EXT4 vs XFS performance on Fedora 17. It recommends EXT4 for databases.