Почему Btrfs является наилучшей выбором файловой системы для SSD в Linux: преимущества и особенности
Для SSD в Linux наиболее рекомендуемой файловой системой является файловая система Btrfs (B-tree файловая система). Вот несколько причин, почему это так:
1. Поддержка TRIM: файловая система Btrfs поддерживает команду TRIM, которая позволяет обеспечить оптимальное управление свободным пространством и увеличивает работоспособность SSD, что позволяет ему работать быстрее и дольше.
2. Копии данных: файловая система Btrfs может регистрировать копии блоков данных на жестком диске для обеспечения целостности данных и защиты от потерь данных.
3. Автоматическое исправление ошибок: Btrfs использует механизмы устранения ошибок для быстрого обнаружения и исправления ошибок как в метаданных, так и в реальных данных. Это повышает надежность файловой системы.
4. Оптимизированное управление работой с данными: Btrfs обеспечивает эффективную работу с большими файлами и множеством маленьких файлов, а также быстрое сохранение данных, что является особенно важным для SSD.
5. Flexible Volume Management: Btrfs поддерживает операции с делением томов, управление квотами и множество других фукнций, что обеспечивает гибкость и лучшее управление.
6. Сжатие данных: Сжатие данных очень актуально для SSD т.к. они имеют сравнительно не большой объем для хранения данных. Btrfs может использовать сжатие данных для экономии места на диске. Однако, не все файлы будут сжаты равномерно, так как это зависит от типа данных, которые хранятся в файлах. Например, текстовые файлы в форматах, таких как TXT, DOC и PDF, могут сжиматься до 50% и более, в то время как фото и видео файлы обычно не поддаются сжатию или сжимаются очень слабо.
Сжатие файлов на Btrfs может быть настраиваемо. Btrfs поддерживает несколько уровней сжатия, а именно:
- zlib: это стандартный уровень сжатия на Btrfs. Сжатие происходит медленно, но обычно дает лучший результат.
- LZO: это метод быстрого сжатия, который уменьшает размер файлов быстро, но менее эффективно, чем zlib.
- Zstd: это относительно новый алгоритм сжатия, который обеспечивает высокую скорость сжатия и хороший результат.
В целом, если на диске много текстовых или других подходящих для сжатия данных, использование сжатия файлов на Btrfs может значительно сэкономить место на диске. Однако, если на диске присутствуют большие файлы, такие как видео и фотографии, которые не могут быть сжаты значительно, то размер сэкономленного места будет гораздо ниже.
Вывод
В целом, Btrfs является лучшим вариантом файловой системы для SSD в Linux, поскольку обладает рядом преимуществ, которые нацелены на повышение производительности устройства и, следовательно, улучшения его долговечности. Однако необходимо отметить, что все зависит от конкретной задачи и условий, при которых используется SSD, поэтому выбор файловой системы должен быть основан на конкретных требованиях пользователя.
Which linux filesystem works best with SSD
The vital TRIM function is supported by the Linux OS starting with 2.6.33 kernel (available early 2010). However, support amongst various filesystems is still inconsistent or not present. Proper partition alignment is also not carried out by installation software.
So, which filesystem works best for SSD and supports TRIM + partition alignment during install and is available on Ubuntu?
4 Answers 4
Short answer
- Choose ext4, and use FITRIM (see below). Also use the noatime option if you fear «SSD wear».
- Don’t change your default I/O scheduler (usually CFQ) on multi-applications servers, as it provides fairness between processes and has automatic SSD support. However, use Deadline on desktops to get better responsiveness under load.
- To easily guarantee proper data alignment, the starting sector of each partition must be a multiple of 2048 (= 1 MiB). You can use fdisk -cu /dev/sdX to create them. On recent distributions, it will automatically take care of this for you.
- Think twice before using swap on SSD. It will probably be much faster compared to swap on HDD, but it will also wear the disk faster (which may not be relevant, see below).
EDIT 2022: NVMe drives can be so quick that apparently, the default I/O scheduler for them in Linux is none / noop . That’s because the time spent in CPU for IO scheduling could take more time than actually directly fetching the data from the drive. So for those drive, I would just leave the default IO scheduler set up by the kernel.
Long answer
Ext4 is the most common Linux filesystem (well maintained). It provides good performance with SSD and supports the TRIM (and FITRIM) feature to keep good SSD performance over time (this clears unused memory blocks for quick later write access). NILFS is especially designed for flash memory drives, but does not really perform better than ext4 on benchmarks. Btrfs is still considered experimental (and does not really perform better either).
The TRIM feature clears SSD blocks that are not used anymore by the filesystem. This will optimize long-term write performance and is recommended on SSD due to their design. It means that the filesystem must be able to tell the drive about those blocks. The discard mount option of ext4 will issue such TRIM commands when filesystem blocks are freed. This is online discard.
However, this behavior implies a little performance overhead. Since Linux 2.6.37, you may avoid using discard and choose to do occasional batch discard with FITRIM instead (e.g. from the crontab). The fstrim utility does this (online), as well as the -E discard option of fsck.ext4 . You will need «recent» (as of writing) versions of these tools however.
You might want to limit writes on your drive as SSD have a limited lifetime in this regard. Don’t worry too much however, today’s worst 128 GB SSD can support at least 20 GB of written data per day for more than 5 years (1000 write cycles per cell). Better ones (and also bigger ones) can last much longer: you will very probably have replaced it by then.
If you want to use swap on SSD, the kernel will notice a non-rotational disk and will randomize swap usage (kernel level wear levelling): you will then see a SS (Solid State) in the kernel message when swap is enabled:
Adding 2097148k swap on /dev/sda1. Priority:-1 extents:1 across:2097148k SS
Also, I agree with most of aliasgar‘s answer (even if most of it has been -illegally?- copied from this website), but I must partly disagree on the scheduler part. By default, the deadline scheduler is optimized for rotational disks as it implements the elevator algorithm. So, let’s clarify this part.
Long answer on schedulers
Starting from kernel 2.6.29, SSD disks are automatically detected, and you may verify this with:
cat /sys/block/sda/queue/rotational You should get 1 for hard disks and 0 for a SSD.
Now, the CFQ scheduler can adapt its behavior based on this information. Since linux 3.1, the kernel documentation cfq-iosched.txt file says:
CFQ has some optimizations for SSDs and if it detects a non-rotational media which can support higher queue depth (multiple requests at in flight at a time), [. ].
Also, the Deadline scheduler tries to limit unordered head movements on rotational disks, based on the sector number. Quoting kernel doc deadline-iosched.txt , fifo_batch option description:
Requests are grouped into «batches» of a particular data direction (read or write) which are serviced in increasing sector order.
However, tuning this parameter to 1 when using a SSD may be interesting:
This parameter tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behaviour). Increasing fifo_batch generally improves throughput, at the cost of latency variation.
Some benchmarks suggest that there is little difference in performance between the different schedulers. Then, why not recommend fairness? when CFQ is rarely bad in the bench.
However, on desktop setups, you will usually experience better responsiveness using Deadline under load, due to its design (probably at a lower throughput cost though).
That said, a better benchmark would try using Deadline with fifo_batch=1 .
To use Deadline on SSDs (and NVMe & flash memory drives) by default, you can create a file, say /etc/udev.d/99-ssd.rules as follows (EDIT 2022: mq-deadline (multi-queues) replaces the deprecated deadline ):
# all non-rotational block devices use 'mq-deadline' scheduler # mostly useful for SSDs on desktops systems SUBSYSTEM=="block", ATTR=="0", ACTION=="add|change", ENV=="disk", ATTR="mq-deadline" File system for an SSD drive
I always thought that traditional file systems, are geared and optimized for non-ssd drive, where, for instance, data locality is important, and fragmentation is problematic. Is there a file system recommended today for SSD drives? Am I better off just using ext4?
4 Answers 4
If the SSD is to be your only disk platform, regardless of number of devices, then you have a quandry; how to minimize writes while maintaining reliability and performance.
More specifically, ext4, and 3 for that matter, NILFS, and almost any other modern file system will maintain a journal. Ordinarily this is desirable, however, when dealing with SSD devices it increases the writes performed against the device and thereby reduces its lifespan. One option is to select a conventional IDE, SATA, or other device to which the file system can write its journal. This way one may maintain the benefits of journaling without sacrificing lifespan of the SSD device(s). In the case of ext4 this can be accomplished as: mke2fs -O journal_dev /dev/external_device then attached to the specific file system as: mkfs.ext4 -J journal=/dev/external_device . More information can be found in the man page.
An additional feature of file systems to keep in mind when deal with SSD devices is atime. Setting atime on a file system can drastically increase the number of writes to a given device over time. Options for changing this behavior include ‘relatime’ and ‘noatime’.
Since we seem to be focusing on ext4, the kernel documentation on the file system, including its available options, is available for reference here.
Some other options to consider: noload , as vorbote suggested, and errors=remount-ro ;