Марк Райтер (Mark Ruijter), автор работающей в пространстве пользователя файловой системы LessFS (http://sourceforge.net/projects/lessfs/) с автоматической дедупликацией, master/slave-репликацией, сжатием и шифрованием данных, представил (http://www.lessfs.com/wordpress/?p=699) свой новый проект - EPRD (http://sourceforge.net/projects/eprd/). В рамках проекта EPRD создана реализация RAM-диска, не теряющего данные за счёт их синхронизации на постоянный носитель. EPRD оформлен в виде модуля для ядра Linux (поддерживаются ядра начиная с 2.6.32). Код проекта распространяется в рамках лицензии GPL.
Как и в классических RAM-дисках, EPRD эмулирует блочное устройство, размещая данные в оперативной памяти, что позволяет достигнуть прекрасной производительности. Одновременно EPRD решает проблему с потерей содержимого RAM-диска после перезапуска, благодаря поддержке синхронизации данных на диск. Для обеспечения непротиворечивости хранимых данных, при сбросе буферов из ОЗУ на постоянный накопитель используется механизм "барьеров", при котором при каждой операции sync() на диск сбрасываются все содержащие изменения буферы, интервал между сбросом буферов задаётся в настройках. Поддерживаются и более простые схемы синхронизации, такие как сброс данных на диск при завершении работы и чтение содержимого при запуске RAM-диска.
В качестве основной области применения проекта рассматривается создание различных дисковых кэшей, позволяющих достигнуть высокой скорости операций случайного доступа к данным на медленных дисках. Интересной особенностью является то, что сбрасываемые на диск данные сохраняются в файл, который имеет формат дискового образа, т.е. его можно примонтировать и использовать без EPRD. Вместо файла-образа можно обеспечить синхронизацию изменений на блочное устройство, что открывает возможность использования EPRD как дополнительной прозрачной прослойки для кэширования в ОЗУ транзитного ввода-вывода для определённых дисковых разделов. Например, выполнив команду "eprd_setup -f /dev/sdc -m 3 -p512M -b" будет создано новое блочное устройство /dev/eprda, ассоциированное с /dev/sdc, кэширующее запросы в буфере размером 512 Мб и сбрасывающие содержимое буферов каждые 3 секунды.
По словам автора EPRD, в настоящее время ведётся работа над созданием нового проекта, который объединит идей, заложенные в EPRD и LessFS. В итоге будет представлено работающее на уровне ядра Linux (в LessFS используется FUSE) высокопроизводительное блочное устройство, поддерживающее автоматическое объединение дубликатов данных.URL: http://www.lessfs.com/wordpress/?p=699
Новость: https://www.opennet.ru/opennews/art.shtml?num=33541
Все гениальное просто. :)
Я бы не сказал. Сначала система загружается с диска в ОЗУ, потом загружается это с диска в ОЗУ, потом это с диска в ОЗУ загружает данные. Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.
> Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.для windows 2003 std это нормальное решение если хотите заюзать более 4гб
PAE появился в pentium pro. Это было до W2003.
2003 Std плевать хотел на PAE
У вас какой-то другой 2003 Std.
> 2003 Std плевать хотел на PAEВы правы, я ошибся. Действительно PAE есть только в Enterprise и Datacenter.
Надо обязательно протестировать!!
два года ждал такую штуку
интересно, а можно такого же добиться, сделав raid1 из ram-диска и обычного?
Элементарно, сделав "обычный" диск write-mostly.
Так ведь и для "обычных" дисковых ФС данные кэшируются в оперативной памяти. И барьеры также используются. А если оперативной памяти достаточно, обращения к диску для чтения могут быть достаточно редкими (я это ясно ощутил, когда проапгрейдился с 2 до 6 GB).Так в чем все-таки соль этого EPRD?
Некоторые туда профиль фокса пихают.
> Некоторые туда профиль фокса пихают.Помогает? Вроде, и так нормально: горячий запуск меньше секунды (как раз за счет кэшей), холодный дольше, но это один раз.
Ну у некоторых он до сих пор секунд по 20-40 запускается, а уж если с сотней табов, да ещё и всех сразу, а не в выгруженном состоянии (там теперь есть опция — не загружать табы сразу при запуске, а лишь по мере надобности). То да, помогает.
Вот только дисковый кэш нужно свести к минимуму — всё равно толку от него при таком раскладе ноль целых и ноль десятых. А вроде можно и вовсе выключить.
> Так в чем все-таки соль этого EPRD?Наверно, в дополнительной гибкости. Можно кэшировать отдельные файлы, а не весь диск; можно принудительно держать файл в памяти.
Тогда следовало именно об этом и писать в новости.
Это вы про домашиний компьютер говорите. Там увеличение оперативки решает проблемы свопа. А если идет интенсинвая запись/чтение, то увеличением оперативки не решить проблему.
Про домашний. Но речь не о свопе, а именно о кэше ФС.
Соль, судя по всему, в том что под кэш фс отводится память по остаточному принципу, а тут выделена конкретная область памяти. Которая в своп не вытеснится, например, или бесполезным (но только что прочитанным\записанным) левым файлом не забьется. Правильно сказали - для домашнего десктопа малополезно, только для случаев интенсивной работы с дисками и некоторой общей нехватке памяти.
> Так в чем все-таки соль этого EPRD?Я, например, живо представил, как использовать такой диск при компиляции: на него могут валиться объектные файлы - объемные, но после компиляции ненужные в принципе. А если идет правка и перекомпиляция каждые пару минут, то и результат, в принципе, не критично потерять...
Впрочем, тут подходит любой RAM-диск без лишних сложностей.
> Так в чем все-таки соль этого EPRD?Из подуманного: попробовать впихнуть место для сборочных чрутов вместо tmpfs, если надоест изредка восстанавливать забытые конфигурации временных сборочных репозиториев под конкретную задачу, аккурат попавшие под ребут. Но и то вряд ли.
Насколько понимаю, соль в обеспечении гораздо большей степени "батчевости" синхронизации на постоянный носитель. Обычная ФС и с кэшированием тормозит на том, что всё-таки беспокоится о долетании записанных в файлы данных до блинов, в отличие от того же tmpfs...
Даже не столько ФС тормозит, сколько в юзерспейсе исторически много вызовов sync/fsync/fdatasync etc. Если с ними бороться "грязными" методами (например глушить через LD_PRELOAD) - то, как показала практика, рано или поздно это кончается проблемами.
Плюс дисковые ФС рассчитаны на медленные устройства, и для хранения таблиц обычно используют разного рода Б-деревья - а хеши для данных, находящихся в памяти, быстрее.
Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша" - и вопрос решён без EPRD.
> Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша"
> - и вопрос решён без EPRD....и получен древний опёнок, где размер кэша при сборке задавался. :)
Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD винт раз в час + UPS - можно неплохо разогнать работу с базой.
Ну разве MS-SQL какой .... Нормальные базы тюнятся на много-рамы-в-кэш и без этого ...
> EPRD оформлен в виде модуля для ядра Linuxи:
> Ну разве MS-SQL какойЯ что-то упустил? :)
Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.
> Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.Скорее, допил wine под запуск mssql.
> Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD
> винт раз в час + UPS - можно неплохо разогнать работу
> с базой.На PostgreSQL с fsync = off можно получить тот же эффект не плодя лишних сущностей.
> На PostgreSQL с fsync = off можно получить тот же эффект не
> плодя лишних сущностей.А раз в час оно синкаться будет?
>> На PostgreSQL с fsync = off можно получить тот же эффект не
>> плодя лишних сущностей.
> А раз в час оно синкаться будет?А зачем? У вас же по условию задачи UPS.
но ведь обычные файловые операции щедро кэшируются в Linux-е - это заметили все у кого много рамы и так... и без этой EPRD будем жить, в оффтопике с этим дела гораздо хуже кстатино буду рад если кому-то EPRD принесет пользу!
Linux с кэшированием - это весч (если только софт не тупорылый как, к примеру, vmware workstation)! У меня на машинке памяти под потолок, так у меня бывает что я фильм запускаю сразу после скачивания - так обращении к винту вообще нет.
Оу, забыл добавить: "EPRD" - тоже весч! Я давно что-то подобное хотел, а тут все уже есть. Будет время - поразбираюсь с ним как следует и покажу (статьей) "мастер-класс" с EPRD (несколько идей давно поселились в голове - ну не зря же я так сильно хотел подобное).
интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с частью хоума на подобный ram-drive-fs раздел?
> интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с
> частью хоума на подобный ram-drive-fs раздел?Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слить и держать его на обычном винте. Сэкономишь кучу памяти и возможно даже денег
ssd в мой ноут стоит дорого. А вот 8 гиг оперативы, из которых 4 можно отвести под рут раздел арча - стоит вполне доступно. Да и интересно было бы поэкспериментировать с таким конфигом.
> Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слитьДа нормальные SSD и так не вызывают желания что-то ещё разгонять, чаще начинает в процессор упираться...
2 yohel: хм, а почему дорого -- явно ж не 2.5" или IDE, если обсуждается 8G RAM?
Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно было напихать и аппаратную поддержку EPRD на нем. Годный будет девайс: очень дешево и очень сердито.// виндузятники - минусуем меня
данафейхоа? вон под заказ тебе ссдху на 40 ТБ вкорячат за бешенобабло.
Вы в своем уме? Вы представляете, какой (и сколько) контроллер памяти нужен для поддержки 256 планок?
Такие девайсы для серверов уже есть, с "аппаратной поддержкой" (память + флеш + конденсаторы для хранения заряда, позволяющего при отключении перелить на флеш), и по множеству причин совершенно не дешево. Но кому нужно, покупает.
FusionIO?
> Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно
> было напихать и аппаратную поддержку EPRD на нем.Благородный дон представляет себе, СКОЛЬКО физически\геометрически места сия куча займёт? Мне навскидку не удалось.
Ну, в здоровый четырехъюнитовый сервак с восемью процами серии Xeon E7 можно впихнуть 128 16-гиговых серверных планок DDR3, итого 2 Тб памяти под кэш и 80 ядер проца. Стоит, правда, эта зараза как самолет и шумит не меньше.
> Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3Если попроще, то уже есть: http://www.pcper.com/reviews/Storage/DDRdrive-hits-ground-ru... (Gigabyte i-RAM был ещё попроще).
Интересная идея...
Кажется, я такую хочу...
Это ж нехило можно "подпереть" любую FS... Или я что-то недопонял?
Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно ли её использовать для /, /boot, /etc?
Глупость!Запись:
- на диск
- в ОПЧтение:
- из ОПС учётом того что скорость чтения флэш очень высокая, а скорость записи низкая, пользы от использования RAM-диска с зеркалированием на SSD немного. Для НЖМД возможны лишь локальные применения для узко-профилированных задач.
У меня работает RAM-диск на 40 Мб без зеркалирования для временных файлов, результатов компиляции и сохранения скачиваемых из интернета файлов (по умолчанию всё на него валится) + этот диск единственный расшарен в локальную сеть для обмена файлами.
> Глупость!Ваня, можно вас попросить: вешайте, пожалуйста, такое предупреждение перед каждым своим постом. Не все еще в курсе вашего амплуа.
По теме: человек говорил о времени жизни SSD, а не о скорости. Вполне логично, что, чем реже и кучнее случается запись на SSD, тем меньше расходуется его резерв.
Запись на SSD случается также часто, как и запись на RAM-диск, чтение с диска не производится вообще.Т.е. мы оставляем слабые места SSD (ресурс жизни и его зависимость к записи, медленную запись) и не используем не одного сильного (скорость чтения).
А теперь ещё раз про глупость.
> Запись на SSD случается также часто, как и запись на RAM-диск, чтение
> с диска не производится вообще.Запись на накопитель в EPRD делается порциями, в зависимости от настроек (по дефолту раз в 3 секунды). Читайте MAN про то, как работают barriers.
> А теперь ещё раз про глупость.
Вот-вот.
> Запись на SSD случается также часто, как и запись на RAM-дискУ нас на линуксе это широко тюнится: /proc/sys/vm/dirty_writeback_centisecs, /proc/sys/vm/dirty_ratio, /proc/sys/vm/dirty_background_ratio вообще и discard,commit=15,nobarrier,delalloc,min_batch_time=1000 (например) для той же ext4.
> А теперь ещё раз про глупость.
Глупость и глупость, весна уже, зачем бы морозить. :)
>> Запись на SSD случается также часто, как и запись на RAM-диск
> У нас на линуксе это широко тюнится: /proc/sys/vm/dirty_writeback_centisecs, /proc/sys/vm/dirty_ratio,
> /proc/sys/vm/dirty_background_ratio вообще и discard,commit=15,nobarrier,delalloc,min_batch_time=1000
> (например) для той же ext4.commit=81600 тогда уж
а вообще для скорости - это tune2fs -o journal_data_writeback (для безбашенных - tune2fs -O ^has_journal)а для бережного использования ssd по-моему ext4 решили не развивать в пользу btrfs (который еще сырой)
> commit=81600 тогда ужНе-не, привёл для /home -- для /var/ftp с локальным зеркалом сизифа совсем другие цифры. :)
>Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту
>прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно
>ли её использовать для /, /boot, /etc?скорее пользу можно ждать, используя прослойку между HDD и кэшем на SSD вместо оперативной памяти. А boot и etc особенно ускорять не нужно.
Жаль раньше не знал про эту приблуду. Совсем недавно решал задачу с клиентскими компьютерами с флешками вместо ЖД: / на squashfs /etc и /home на nfs, ну а /tmp на tmpfs. Вот и ломал голову с /var, куда бы его деть
Тут основной вопрос - как оно восстанавливается после загрузки. Если полностью надо ждать чтения с диска, то фигня.
> В итоге будет представлено работающее на уровне ядра Linux (в LessFS используется FUSE) высокопроизводительное блочное устройство, поддерживающее автоматическое объединение дубликатов данных.Единственная более-менее понятная и обнадеживающая новость.
А смысл EPRD непонятен совершенно - чем оно отличается от обычной ФС с большим кешем?
Давно ждал. Вот если grub еще научится ядро грузить из такого диска.
Вопрос: зачем???
Не проще ли ядро читать с обычного раздела, если чтение при загрузке всё равно идёт с диска?
А запись в /boot так и вообще происходит раз в пятилетку...
> Давно ждал. Вот если grub еще научится ядро грузить из такого диска.А в чем профит? Лучше уж /boot на ssd вынести.
вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья навеяла.
Нет. Спасибо Adobe за это!
Вопрос был про другой флеш - про флешку, которую Винды научились использовать как быстрый своп, чтобы ускорить загрузку системы.
В Линуксе же есть возможность и вынести систему на сколь угодно быстрый носитель, и оптимизировать загрузку непосредственно, оставив в ней только необходимое. Это куда эффективнее, чем подпирание наследственных болезней "передовыми технологиями". Но, конечно, это не выглядит как привлекательный товар. Хотя бы потому, что это не товар.
> Вопрос был про другой флеш - про флешку, которую Винды научились использовать
> как быстрый своп, чтобы ускорить загрузку системы.Intel TurboMemory[1] в линуксе до сих пор не поддерживается (у меня под руками гиг такого флэша в X61t воткнутым приехал, всё не доходят выкинуть его, чтоб свои милли/микроамперы не жрал) -- поскольку интел сам потом понял бессмысленность всей затеи в корне.
[1] http://www.thinkwiki.org/wiki/Intel®_Turbo_Memory_hard_...
> вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно
> как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья
> навеяла.Это по-моему и в винде новой уже выпилили в связи с неудачностью изначальной идеи.
На десктопе (что в винде, что в линуксе) для сколько-нибудь приличной производительности своп должен быть отключен.