Для SquashFS представлены (http://lkml.org/lkml/2013/11/19/630) патчи, существенно ускоряющие работу данной файловой системы. Squashfs является специализированной файловой системой, работающей в режиме "только для чтения". Отличительной особенностью данной файловой системы является очень компактное представление метаданных и хранение данных в сжатом виде. Наиболее востребованным применением SquashFS является использование в качестве файловой системы для установочных образов, Live-систем и прошивок. Пока не ясно, войдет ли данный патч в состав ядра 3.13, окно приёма изменений для которого будет закрыто на днях.
В данной серии патчей представлено множество оптимизаций производительности. В ряде случаев скорость работы Squashfs может увеличиться в несколько раз. Наиболее заметными изменениями являются реализация многопоточной распаковки сжатых данных и параллельного ввода вывода. Если в системе с несколькими ядрами смонтировано несколько образов squashfs, работа с ними может существенно ускориться. Кроме того, реализована распаковка сразу в кэш страниц (page cache), что также может существенно ускорить ряд операций с файловой системой. В зависимости от конфигурации, выигрыш в скорости может составлять до нескольких раз (в одном из тестов скорость возросла с 13 MB/s до 67 MB/s).URL: http://www.phoronix.com/scan.php?page=news_item&px=MTUyMDQ
Новость: http://www.opennet.me/opennews/art.shtml?num=38484
Опять похороникс. И опять сравнивали скорость последовательного чтения данных (схем, графиков и примеров по ссылке не вижу).
А пофиг что фороникс. Там реально изменения которые дадут профит. Многопоточная декомпрессия по любому свое возьмет в ряде конфиг, декомпрессия в page cache - тоже.
и как оно по сравнению с clicfs? по прежнему тормозит?
> и как оно по сравнению с clicfs? по прежнему тормозит?А clicfs вроде как не ФС [хранящая данные на блочном устройстве или в файле] а лишь какой-то оверлей [объединяющий несколько ФС для фэйковых записей]. Или я чего-то не понял?
А файловые системы кроме точек /var /home стоит использовать SquashFS? Реально получить прибавку в скорости?
Это файловая система только для чтения.
Её имеет смысл использовать только для initrd, ну максимум - /usr:/opt:/etc
> Это файловая система только для чтения.Это по сути тарбол. (PS: как и iso9660)
> Её имеет смысл использовать только для initrd
Да можно и на голову надевать, но лучше не надо. :)
> Это по сути тарбол. (PS: как и iso9660)Только с быстрым доступом к оглавлению и файлам "на лету", без декомпрессии немеряных гигазов. И даже запуском программ прямо так (XIP - execution in place). Тарболам ничего подобного и не снилось. Некое подобие можно сгородить через FUSE, но будет намного кривее и грабельнее.
>> Её имеет смысл использовать только для initrd
> Да можно и на голову надевать, но лучше не надо. :)Интересно, почему именно initrd. Ее обычно пользуют как readonly базу. На ливсидюках, например. Или как failsafe режим openwrt например. Далее к этому через оверлей (unionfs, minifo, ...) цепляют writeable файловую систему (ливсидюки обычно рам-диски, openwrt - как правило JFFS) и получается гибридная ФС, где есть неубиваемая база и временный/опциональный оверлей с изменениями относительно нее.
>> Это по сути тарбол. (PS: как и iso9660)
> Только с быстрым доступом к оглавлению и файлам "на лету"В том плане, что rw не предусмотрено.
>>> Её имеет смысл использовать только для initrd
>> Да можно и на голову надевать, но лучше не надо. :)
> Интересно, почему именно initrd. Ее обычно пользуют как readonly базу.Именно. Для initrd в том же альте когда-то применяли romfs и экономили на том чуточку памяти, но с появлением initramfs перебрались на неё.
[угу]
> В том плане, что rw не предусмотрено.Ну да, там упор на простой и максимально компактный дизайн. Поэтому squashfs при прочих равных заметно компактнее например JFFS с теми же данными.
> экономили на том чуточку памяти, но с появлением initramfs перебрались на неё.
Не, ну в принципе делать начальный rootfs на squash ничему не противоречит, openwrt как-то так и делают, но это все-таки не рамдиск. Рамдиск может быть подгружен в память бутлоадером или даже приаттачен к ядру, etc - так что ядру не надо знать как и где это брать, в чем собственно и пойнт: взлетевшая оттуда система уже займется продвинутым монтированием всякой экзотики. А squashfs для такого никогда не создавался. Хотя наверное и можно как-то так заюзать при должном желании.
>В том плане, что rw не предусмотрено.Это у тебя не предусмотрено.
А у меня предусмотрено:mount -o remount,rv ...
и можешь "писАть".
> mount -o remount,rv ...Опечатка. Правильно:
mount -o remount,rw ...
конечно же:)
> и можешь "писАть".В squashfs то? Ну да, удачи в нее записать что-нибудь таким макаром :)
> Это файловая система только для чтения.Если под "Это" подразумевалось squashfs то спасибо вам капитан!
Но вот только сам по себе squashfs нужен гораздо реже чем squashfs+{unionfs,funionfs,unionfs-fuse,aufs,overlayfs} а это уже ВНЕЗАПНО никак не ro а rw такие дела.
Есть пример использования squashfs для раздачи portage. Раз в сутки делается squashfs-образ дерева портеджей и раз в сутки этот образ копируют себе клиентские машины и монтируют локально. Работает довольно быстро и очень удобно.
Использую для дерева portage. ~170 тысяч файлов умещаются в 90 МБ, с lzo сжатием. При обновлении, правда, чуть больше операций выполнять надо: rsync'нуть в tmpfs, отмонтировать /usr/portage, mount -o bind *** /usr/portage и т. п.
Зачем? Несжатый portage займёт на диске не намного больше места, но доступ к нему будет сильно быстрее. Или ты образ squashfs копируешь в tmpfs, и монтируешь уже оттуда?
> будет сильно быстрее.А вот не факт. LZO быстро декомпрессуется, оглавление в squashfs доступно как и в любой иной ФС, т.е. довольно быстро. На не очень быстром диске можно даже по скорости выиграть за счет LZO сжатия, если все в диск упиралось.
>> будет сильно быстрее.
> А вот не факт. LZO быстро декомпрессуется, оглавление в squashfs доступно как
> и в любой иной ФС, т.е. довольно быстро. На не очень
> быстром диске можно даже по скорости выиграть за счет LZO сжатия,
> если все в диск упиралось.Да, пожалуй зависит от соотношения проц/диск.
Именно. Разница во времени выполнения "emerge -evp @world" раза в 3-4 сокращается, но разве что пока кеш пустой. Вобщем, это из разряда "хочется странного".
теперь будем ждать чтобы это попало в ядро, потом попало в популярные livecd, потом чтобы руки дошли запустить это и МОЖЕТ БЫТЬ увидеть разницу в пару секунд
Успокойся, эти доработки сделаны не для тебя.
да я только за, вот только для чего это на практике?
> да я только за, вот только для чего это на практике?На практике это для тех мест где нужно одновременно сжатие кучи файлов с сохранением всех posix прав и с возможностью простого монтирования на ro либо немного более сложнее организуемого монтирования на rw.
Конкретно для "корня" в чуть менее чем во ВСЕХ live cd/dvd/usb дистрибутивах используется squashfs и во многих можно даже сохранять свои изменения т.е. есть и то самое rw.
> Конкретно для "корня" в чуть менее чем во ВСЕХ live cd/dvd/usb дистрибутивах
> используется squashfsКажется, в openSUSE свой совмещённый clicfs.
> и во многих можно даже сохранять свои изменения т.е. есть и то самое rw.
Как уже отмечали, это реализуется оверлейными ФС => на другом уровне.
Впрочем, все и так всё знают. :)
>Как уже отмечали, это реализуется оверлейными ФС => на другом уровне.Или стандартными "оверлейными" (вернее, CoW-over-md) блок-девайсами (как в федоре).
я не о файловой системе, а конкретно об этом улучшающем патче.
> я не о файловой системе, а конкретно об этом улучшающем патче.А что плохого в более эффективной параллелизации во время когда однопроцессорные системы еще нужно поискать?
плохого то ничего, вот только кому на практике это нужно, кто на практике заметит разницу?
> плохого то ничего, вот только кому на практике это нужно, кто на практике заметит разницу?На практике разницу увидит тот кто это реально использует а не фантазирует на тему "кому же оно нужно? и нужно ли оно вообще?".
Но в САМОМ ГЛАВНОМ, в knoppix, используется cloop :)
Для embedded-систем, конечно же
> Для embedded-систем, конечно жеТакже находит применение для ливцд и прочая.
> да я только за, вот только для чего это на практике?Например у меня из корня в squashfs, загружаемого по tftp, тонкие клиенты работают.
> разницу в пару секундНу так хуже никому не станет. А лучше - запросто.
Я держу backup-образы используя squashfs с xz. Лично для меня этот патч весьма полезен :)
А ведь не самый плохой способ применения. Заморачивался на дельты? или просто монтируемый через -o loop date-hour:mm:sec.fileext ?
> А ведь не самый плохой способ применения. Заморачивался на дельты? или просто
> монтируемый через -o loop date-hour:mm:sec.fileext ?А зачем там заморочки с дельтами? Если для экономии места то это глупость потому что сжатие {gzip,LZMA,LZO,xz} решает эту проблему и кроме при такой потребности того любой бекап можно просто взять и примонтировать. Так что я вангую что там никаких дельт и близко нет.
> глупость потому что сжатие {gzip,LZMA,LZO,xz} решает эту проблемуНу да, попробуй сжать .avi/.mkv/... хоть чем-то из этого и выиграть более ~десятка процентов в лучшем случае. А вот при использовании бэкапа с дельтами второй раз сохраняться одно и то же не будет.
> такой потребности того любой бекап можно просто взять и примонтировать.
Только места на хранение потребуется вагон.
на openwrt, тот же SquashFSЖдем ускорения иницилизации роутера!
Заодно расскажите, где прикупить роутер с многоядерным процессором за разумные деньги. ;)
P1020EWLAN не предлагать: в наших пердях не продаётся и стоит неразумно.
>Кроме того, реализована распаковка сразу в кэш страниц (page cache), что также может >существенно ускорить ряд операций с файловой системой.Читай целиком новость.
> в наших пердях не продаётсяИ почту в ваших пердях не принимают?
> Пока не ясно, войдет ли данный патч в состав ядра 3.13Всё это УЖЕ в мэйнлайне.
ну и где брать эти патчи? я как раз упаковал дерево портежа в squashfs, но паковка очень уж медленная
> ну и где брать эти патчи? я как раз упаковал дерево портежа"Портаджи распаковывать" научился, а по ссылкам ходить - нет?
> в squashfs, но паковка очень уж медленная
Наверное, ещё и новость не прочитал, торопыга? Там не про это.
Ну сходи по ссылкам и найди мне там патчи.
> Ну сходи по ссылкам и найди мне там патчи.lkml.org/lkml/2013/11/19/627 На, убогий, пользуйся. Я сегодня добрый.
> ну и где брать эти патчи? я как раз упаковал дерево портежа
> в squashfs, но паковка очень уж медленнаяgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git