Tag Info

Hot answers tagged

7

You probably just want to use XFS. It's quite capable of what you're asking for, and does the job. There's no reason to complicate this with lesser-used filesystems, which can come with other tradeoffs. Please see: How does the number of subdirectories impact drive read / write performance on Linux? and The impact of a high directory-to-file ratio on XFS ...


4

If you are just following orders, please ask the person issuing them how much usable space each filesystem needs for present and future requirements. You want to make sure that you're not creating nearly-full filesystems from the start! This approach to filesystem allocation is not scalable, so I strongly suggest that it be redesigned with a more modern ...


3

There seems to be a known bug in the dir_index feature (which you should be able to disable) that is caused by hashes of filenames colliding: http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html


2

If it is read-only, why to not use a ISO file? You can use genisoimage or mkisofs. If you want to compress the whole thing, you can also use squashfs, another read-only filesystem with very high compression ratio.


2

Seeing the number of small files, I would consider using SquashFS. Especially if you have powerful enough CPU (meaning no Pentium III, or 1GHz ARM). Depending on the type of data stored, SquashFS can greatly reduce its size and thus the I/O when reading it. Only downside is CPU usage on read. On the other hand, any modern CPU can decompress at speeds far ...


1

I am not sure if this fits your purpose, but have you considered tar to combine multiple files? That might decrease the pressure and space requirements on the filesystem, and your database application can read data for a specific file with one of the many tar libraries around. Depending on your access pattern this might even increase the performance.


1

stat is not the right tool to investigate block devices. Here is an example of using --set-capacity: root@maxim:~# blockdev --getsize64 /dev/loop0 0 root@maxim:~# dd if=/dev/zero of=/tmp/aaa.img count=10 bs=1M 10+0 записей получено 10+0 записей отправлено скопировано 10485760 байт (10 MB), 0,00709284 c, 1,5 GB/c root@maxim:~# blockdev --getsize64 ...


1

I see that dummzeuch find a solution to his problem but there is actually one more case I found where disk can have enough inodes/free space and still showing "no space left on the device" while attempting to transfer certain directories. This is caused by hash collisions on block devices formatted with ext4 file system where directory indexing is enabled ...



Only top voted, non community-wiki answers of a minimum length are eligible