Из серии: Чего нет в Optware
Коллеги, хочу вам продемонстрировать работу механизма posix_fallocate в rtorrent. Это, в первую очередь касается тех пользователей, которые используют роутер в качестве файлокачалки.
Тест №1. Без posix_fallocate.
Исходные данные:- привычный rtorrent 0.8.6. из Optware,
- файловая система ext3,
- контент торрента - 18Мб.
Запускаем торрент, добавляем закачку и смотрим как изменяется размер скачиваемого файла:
Code:
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
1.1M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
4.6M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
6.8M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
7.9M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
18.2M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
Видно, что место под файл на диске выделяется в процессе скачивания. Оценим насколько фрагментированным получился файл:
Code:
$ filefrag /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
/tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe: 586 extents found, perfection would be 1 extent
Г-ди долбаный Иисусе! 586 ошмётков по всему диску! Сколько бы не говорили адепты unix про то, что ext3 не нуждается в дефрагментации, я не поверю, что этот файл будет считан быстро из-за метаний головки по всей поверхности диска.
Тест №2. С posix_fallocate.
- rtorrent 0.8.9. из моего репозитория,
- файловая система ext4,
- тот же торрент объёмом 18Мб.
Запускаем rtorrent, добавляем закачку и приглядываемся к размеру контента на диске:
Code:
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
18.2M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
$ du -h /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
18.2M /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
Другими словами, место под файл выделяется целиком и мгновенно. Дефрагментация файла после скачивания...
Code:
$ filefrag /tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe
/tmp/downloads/torrent/Cave_Story_Plus_v1.0_setup.exe: 1 extent found
...отстутствует вовсе.
Конечно же, не всегда файл можно записать на диске одним куском, но полугигабайтные файлы у меня фрагментируются всего на 3-4 куска. Механизм posix_fallocate будет работать только на файловых системах ext4 или xfs. Как подключить раздел ext4 смотрите в профильной теме.
Quote:
Originally Posted by
lly
Интересно, чтобы кто-нибудь осилил
пересборку торрента с поддержкой posix_fallocate и погонял, т.к. это работает только на xfs и ext4.
не-не-не:) Никто:)
О взаимозависимости прошивки и репозитория
Quote:
Originally Posted by
lly
Как вариант, только сам opkg можно собрать каким-нибудь древним тулчейном на базе uClibc 0.9.30 который запустится везде, а затем выкачает новую uClibc-opt. Вот только надо ли?
Как скажешь, так и сделаю. Коль скоро ссылка в /etc/ipkg.conf когда-нибудь будет вести в новый репозиторий, можно оставить как есть. С определённого релиза всё будет работать, до - нет.
Кстати, уже "накопились" две причины для пересобрки библиотеки uClibc:
- для включения -Wl,-rpath,/opt/lib.
- для включения UCLIBC_HAS_LOCALE=y, так как без этого все ncurses-based приложения будут показывать крокозябры вместо кириллици - htop, rtorrent, ncurses-mc, screen и прочие.
Оба пункта спорные. Первый, например, позволит "развязать" прошивочные библиотеки с репозиторийными, что уберёт указанный в предыдущем посте косяк с opkg. "Развязка" потенциально обрадует томатовцев, но "отдалит" репозиторий от прошивки. Надо ли?
А с другой стороны, если не выполнить развязку, то придётся обеспечить синхронность релизов прошивки и репозитория, что в свою очередь, не удобно ни мне, ни пользователям. Выходит, что развязка и фиксация версии uClibc в какой-то момент неизбежна.
Чо делать? Куда бечь?