What fs to put for small files on microSD in linux?

Question

linux

There is a web server on Raspberry pi 3b (the store is spinning on opencart). Used as a backup solution in case of emergency. The disk is MicroCD (SanDisck), Raspbian OS.

The speed of the disk is very depressing. FS is now EXT4 with logging disabled. I decided to move the directory with the site (a bunch of small files) into a separate section. Could you tell me which FS is better to use for these purposes? Is there anything faster when working with small files than EXT4 with off. journaling?

PS The system itself was optimized as best I could, all the logs, tmp, var..., lock, run have already been moved to ram. Flushing caches to disk reduced it.d.

Answer 1

ext2.
Maybe vfat.

Answer 2

In this situation, the choice of the optimal file system will depend on the most frequently performed operations on files, because the number of inodes for journaled file systems can be specified during markup other than the standard one.
We found the results of testing several different file systems on the same operations. Each operation was performed on 30,000 files, after which the average operation time was taken. The benchmark itself is available online and can be used by you to conduct an independent test. https://www.dropbox.com/s/viba8rzdq6uegsq/bench.py?dl=0
Using Linux Kernel version 3.1.7
Btrfs:
create: 53 s
rewrite: 6 s
read sq: 4 s
read rn: 312 s
delete: 373 s
ext4:
create: 46 s
rewrite: 18 s
read sq: 29 s
read rn: 272 s
delete: 12 s
ReiserFS:
create: 62 s
rewrite: 321 s
read sq: 6 s
read rn : 246 s
delete: 41 s
XFS:
create: 68 s
rewrite: 430 s
read sq: 37 s read rn
: 367 s
delete: 36 s
The XFS file system in this test showed poor results, but it is still popular for systems where you need to store large amounts of information. It is also usually recommended to use it in non-standard configurations, because initially it is somewhat more tailored for customization flexibility.
Also, based on the results of this comparative testing, we note that in a situation where the main repetitive operations are reading from and writing to files, and deleting files is rare, Btrfs is a possible optimal choice, slightly inferior to ext4 in file creation speed, but giving better performance reading and writing to an already existing file.
In addition, we add that often for cases where it is necessary to work with large numbers of files, it is enough to use ext4 with a non-standard (increased) number of inodes when partitioning a disk. This allows, among other things, not to abandon the use of the journal, due to which it is possible to "squeeze the maximum" of its capabilities out of the file system.
In conclusion, we add that in situations where it is necessary to place huge amounts of small files of the same type, you can contact the project developer to revise the storage mechanism itself. If the content structure of these files is constant and the maximum size is known, a database can be used instead by creating a table in it with columns corresponding to the content structure of the specified files. This will allow placing data in actually one main file (many databases store tables in the form of pairs of files, one of which describes the structure of the table, and the other stores its contents), and the tasks of writing and reading will be shifted to the DBMS, at the settings level of which they can be optimize. The disadvantage of this approach is the need to replace the functions of interaction with files with the functions of interaction with the DBMS in the scripts of the site itself.