The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

EPRD - реализация RAM-диска, обеспечивающего постоянное хранение данных

05.04.2012 19:09

Марк Райтер (Mark Ruijter), автор работающей в пространстве пользователя файловой системы LessFS с автоматической дедупликацией, master/slave-репликацией, сжатием и шифрованием данных, представил свой новый проект - 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) высокопроизводительное блочное устройство, поддерживающее автоматическое объединение дубликатов данных.

  1. Главная ссылка к новости (http://www.lessfs.com/wordpres...)
  2. OpenNews: RapidDisk 1.0 - новая реализация RAM-диска для Linux
  3. OpenNews: Сетевая файловая система с кэшированием данных
  4. OpenNews: Facebook открыл модуль Flashcache для организации кэширования на SSD-накопителях
  5. OpenNews: FS-Cache - инфраструктура локального кэширования для сетевых файловых систем
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/33541-eprd
Ключевые слова: eprd, ramdisk, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, sashka_ua (?), 19:33, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Все гениальное просто. :)
     
     
  • 2.76, dvfv (?), 09:58, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы не сказал. Сначала система загружается с диска в ОЗУ, потом загружается это с диска в ОЗУ, потом это с диска в ОЗУ загружает данные. Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.
     
     
  • 3.77, Andrey (??), 10:29, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.

    для windows 2003 std это нормальное решение если хотите заюзать более 4гб

     
     
  • 4.80, Forth (??), 22:44, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    PAE появился в pentium pro. Это было до W2003.
     
     
  • 5.82, Аноним (-), 00:19, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    2003 Std плевать хотел на PAE
     
     
  • 6.88, Forth (??), 16:29, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У вас какой-то другой 2003 Std.
     
  • 6.90, Forth (??), 16:33, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 2003 Std плевать хотел на PAE

    Вы правы, я ошибся. Действительно PAE есть только в Enterprise и Datacenter.

     

  • 1.3, chemtech (ok), 19:34, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надо обязательно протестировать!!

     
  • 1.4, name (??), 19:56, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    два года ждал такую штуку
     
  • 1.5, Нанобот (?), 19:57, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно, а можно такого же добиться, сделав raid1 из ram-диска и обычного?
     
     
  • 2.7, Dm_R (?), 20:02, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Элементарно, сделав "обычный" диск write-mostly.
     

  • 1.9, Tav (ok), 20:13, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Так ведь и для "обычных" дисковых ФС данные кэшируются в оперативной памяти. И барьеры также используются. А если оперативной памяти достаточно, обращения к диску для чтения могут быть достаточно редкими (я это ясно ощутил, когда проапгрейдился с 2 до 6 GB).

    Так в чем все-таки соль этого EPRD?

     
     
  • 2.11, Lain_13 (?), 20:19, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Некоторые туда профиль фокса пихают.
     
     
  • 3.19, Tav (ok), 21:51, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Некоторые туда профиль фокса пихают.

    Помогает? Вроде, и так нормально: горячий запуск меньше секунды (как раз за счет кэшей), холодный дольше, но это один раз.

     
     
  • 4.35, Lain_13 (?), 01:50, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну у некоторых он до сих пор секунд по 20-40 запускается, а уж если с сотней табов, да ещё и всех сразу, а не в выгруженном состоянии (там теперь есть опция — не загружать табы сразу при запуске, а лишь по мере надобности). То да, помогает.
    Вот только дисковый кэш нужно свести к минимуму — всё равно толку от него при таком раскладе ноль целых и ноль десятых. А вроде можно и вовсе выключить.
     
  • 2.13, Аноним (-), 21:11, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в чем все-таки соль этого EPRD?

    Наверно, в дополнительной гибкости. Можно кэшировать отдельные файлы, а не весь диск; можно принудительно держать файл в памяти.

     
     
  • 3.18, Tav (ok), 21:48, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда следовало именно об этом и писать в новости.
     
  • 2.14, grondek (?), 21:32, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы про домашиний компьютер говорите. Там увеличение оперативки решает проблемы свопа. А если идет интенсинвая запись/чтение, то увеличением оперативки не решить проблему.
     
     
  • 3.17, Tav (ok), 21:47, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Про домашний. Но речь не о свопе, а именно о кэше ФС.
     
  • 2.20, антоним (?), 22:13, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Соль, судя по всему, в том что под кэш фс отводится память по остаточному принципу, а тут выделена конкретная область памяти. Которая в своп не вытеснится, например, или бесполезным (но только что прочитанным\записанным) левым файлом не забьется. Правильно сказали - для домашнего десктопа малополезно, только для случаев интенсивной работы с дисками и некоторой общей нехватке памяти.
     
  • 2.38, тоже Аноним (ok), 08:51, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так в чем все-таки соль этого EPRD?

    Я, например, живо представил, как использовать такой диск при компиляции: на него могут валиться объектные файлы - объемные, но после компиляции ненужные в принципе. А если идет правка и перекомпиляция каждые пару минут, то и результат, в принципе, не критично потерять...
    Впрочем, тут подходит любой RAM-диск без лишних сложностей.

     
  • 2.91, Michael Shigorin (ok), 16:50, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в чем все-таки соль этого EPRD?

    Из подуманного: попробовать впихнуть место для сборочных чрутов вместо tmpfs, если надоест изредка восстанавливать забытые конфигурации временных сборочных репозиториев под конкретную задачу, аккурат попавшие под ребут.  Но и то вряд ли.

    Насколько понимаю, соль в обеспечении гораздо большей степени "батчевости" синхронизации на постоянный носитель.  Обычная ФС и с кэшированием тормозит на том, что всё-таки беспокоится о долетании записанных в файлы данных до блинов, в отличие от того же tmpfs...

     
     
  • 3.97, Алексей Поляков (?), 13:51, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже не столько ФС тормозит, сколько в юзерспейсе исторически много вызовов sync/fsync/fdatasync etc. Если с ними бороться "грязными" методами (например глушить через LD_PRELOAD) - то, как показала практика, рано или поздно это кончается проблемами.
    Плюс дисковые ФС рассчитаны на медленные устройства, и для хранения таблиц обычно используют разного рода Б-деревья - а хеши для данных, находящихся в памяти, быстрее.
     

  • 1.21, антиантоним (?), 22:32, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша" - и вопрос решён без EPRD.
     
     
  • 2.92, Michael Shigorin (ok), 16:51, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша"
    > - и вопрос решён без EPRD.

    ...и получен древний опёнок, где размер кэша при сборке задавался. :)

     

  • 1.22, Rico (??), 22:52, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD винт раз в час + UPS - можно неплохо разогнать работу с базой.
     
     
  • 2.26, Anonymouse (?), 23:55, 05/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну разве MS-SQL какой .... Нормальные базы тюнятся на много-рамы-в-кэш и без этого ...
     
     
  • 3.47, an. (?), 12:15, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > EPRD оформлен в виде модуля для ядра Linux

    и:
    > Ну разве MS-SQL какой

    Я что-то упустил? :)

     
     
  • 4.73, Аноним (-), 23:48, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.
     
     
  • 5.85, Аноним (-), 00:39, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.

    Скорее, допил wine под запуск mssql.

     
  • 2.81, Forth (??), 22:48, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD
    > винт раз в час + UPS - можно неплохо разогнать работу
    > с базой.

    На PostgreSQL с fsync = off можно получить тот же эффект не плодя лишних сущностей.

     
     
  • 3.86, Аноним (-), 00:39, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На PostgreSQL с fsync = off можно получить тот же эффект не
    > плодя лишних сущностей.

    А раз в час оно синкаться будет?

     
     
  • 4.89, Forth (??), 16:31, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> На PostgreSQL с fsync = off можно получить тот же эффект не
    >> плодя лишних сущностей.
    > А раз в час оно синкаться будет?

    А зачем? У вас же по условию задачи UPS.

     

  • 1.23, добрый дядя (?), 23:20, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    но ведь обычные файловые операции щедро кэшируются в Linux-е - это заметили все у кого много рамы и так... и без этой EPRD будем жить, в оффтопике с этим дела гораздо хуже кстати

    но буду рад если кому-то EPRD принесет пользу!

     
     
  • 2.30, Аноним (-), 00:26, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Linux с кэшированием - это весч (если только софт не тупорылый как, к примеру, vmware workstation)! У меня на машинке памяти под потолок, так у меня бывает что я фильм запускаю сразу после скачивания - так обращении к винту вообще нет.
     
     
  • 3.32, Аноним (-), 00:29, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оу, забыл добавить: "EPRD" - тоже весч! Я давно что-то подобное хотел, а тут все уже есть. Будет время - поразбираюсь с ним как следует и покажу (статьей) "мастер-класс" с EPRD (несколько идей давно поселились в голове - ну не зря же я так сильно хотел подобное).
     

  • 1.27, yohel (?), 00:03, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с частью хоума на подобный ram-drive-fs раздел?
     
     
  • 2.36, Lain_13 (?), 01:59, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с
    > частью хоума на подобный ram-drive-fs раздел?

    Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слить и держать его на обычном винте. Сэкономишь кучу памяти и возможно даже денег

     
     
  • 3.71, yohel (?), 22:23, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ssd в мой ноут стоит дорого. А вот 8 гиг оперативы, из которых 4 можно отвести под рут раздел арча - стоит вполне доступно. Да и интересно было бы поэкспериментировать с таким конфигом.
     
  • 3.93, Michael Shigorin (ok), 16:54, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слить

    Да нормальные SSD и так не вызывают желания что-то ещё разгонять, чаще начинает в процессор упираться...

    2 yohel: хм, а почему дорого -- явно ж не 2.5" или IDE, если обсуждается 8G RAM?

     

  • 1.29, Аноним (-), 00:23, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно было напихать и аппаратную поддержку EPRD на нем. Годный будет девайс: очень дешево и очень сердито.

    // виндузятники - минусуем меня

     
     
  • 2.31, кевин (?), 00:26, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    данафейхоа? вон под заказ тебе ссдху на 40 ТБ вкорячат за бешенобабло.
     
  • 2.33, Stax (ok), 00:50, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы в своем уме? Вы представляете, какой (и сколько) контроллер памяти нужен для поддержки 256 планок?
    Такие девайсы для серверов уже есть, с "аппаратной поддержкой" (память + флеш + конденсаторы для хранения заряда, позволяющего при отключении перелить на флеш), и по множеству причин совершенно не дешево. Но кому нужно, покупает.
     
  • 2.34, Oleksiy Kovyrin (?), 01:36, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    FusionIO?
     
  • 2.39, ryoken (?), 09:03, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно
    > было напихать и аппаратную поддержку EPRD на нем.

    Благородный дон представляет себе, СКОЛЬКО физически\геометрически места сия куча займёт? Мне навскидку не удалось.

     
     
  • 3.75, Аноним (-), 07:13, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, в здоровый четырехъюнитовый сервак с восемью процами серии Xeon E7 можно впихнуть 128 16-гиговых серверных планок DDR3, итого 2 Тб памяти под кэш и 80 ядер проца. Стоит, правда, эта зараза как самолет и шумит не меньше.
     
  • 2.94, Michael Shigorin (ok), 18:34, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3

    Если попроще, то уже есть: http://www.pcper.com/reviews/Storage/DDRdrive-hits-ground-running-PCI-E-RAM-b (Gigabyte i-RAM был ещё попроще).

     

  • 1.40, Аноним (-), 09:21, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересная идея...
    Кажется, я такую хочу...
    Это ж нехило можно "подпереть" любую FS... Или я что-то недопонял?
     
  • 1.41, alex.h (??), 10:18, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно ли её использовать для /, /boot, /etc?
     
     
  • 2.44, Ваня (??), 11:02, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Глупость!

    Запись:
    - на диск
    - в ОП

    Чтение:
    - из ОП

    С учётом того что скорость чтения флэш очень высокая, а скорость записи низкая, пользы от использования RAM-диска с зеркалированием на SSD немного. Для НЖМД возможны лишь локальные применения для узко-профилированных задач.

    У меня работает RAM-диск на 40 Мб без зеркалирования для временных файлов, результатов компиляции и сохранения скачиваемых из интернета файлов (по умолчанию всё на него валится) + этот диск единственный расшарен в локальную сеть для обмена файлами.

     
     
  • 3.49, тоже Аноним (ok), 12:42, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Глупость!

    Ваня, можно вас попросить: вешайте, пожалуйста, такое предупреждение перед каждым своим постом. Не все еще в курсе вашего амплуа.

    По теме: человек говорил о времени жизни SSD, а не о скорости. Вполне логично, что, чем реже и кучнее случается запись на SSD, тем меньше расходуется его резерв.

     
     
  • 4.50, Ваня (??), 12:46, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Запись на SSD случается также часто, как и запись на RAM-диск, чтение с диска не производится вообще.

    Т.е. мы оставляем слабые места SSD (ресурс жизни и его зависимость к записи, медленную запись) и не используем не одного сильного (скорость чтения).

    А теперь ещё раз про глупость.

     
     
  • 5.52, Аноним (-), 12:49, 06/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Запись на SSD случается также часто, как и запись на RAM-диск, чтение
    > с диска не производится вообще.

    Запись на накопитель в EPRD  делается порциями, в зависимости от настроек (по дефолту  раз в 3 секунды). Читайте MAN про то, как работают barriers.

    > А теперь ещё раз про глупость.

    Вот-вот.

     
  • 5.95, Michael Shigorin (ok), 18:40, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Запись на 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.

    > А теперь ещё раз про глупость.

    Глупость и глупость, весна уже, зачем бы морозить. :)

     
     
  • 6.99, Алексей Поляков (?), 14:03, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Запись на 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 (который еще сырой)

     
     
  • 7.100, Michael Shigorin (ok), 00:12, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > commit=81600 тогда уж

    Не-не, привёл для /home -- для /var/ftp с локальным зеркалом сизифа совсем другие цифры. :)

     
  • 2.78, Pilat (ok), 13:07, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту
    >прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно
    >ли её использовать для /, /boot, /etc?

    скорее пользу можно ждать, используя прослойку между HDD и кэшем на SSD вместо оперативной памяти. А boot и etc особенно ускорять не нужно.

     

  • 1.68, SuseUser (?), 18:38, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жаль раньше не знал про эту приблуду. Совсем недавно решал задачу с клиентскими компьютерами с флешками вместо ЖД: / на squashfs /etc и /home на nfs, ну а /tmp на tmpfs. Вот и ломал голову с /var, куда бы его деть
     
  • 1.69, дядя (?), 19:21, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тут основной вопрос - как оно восстанавливается после загрузки. Если полностью надо ждать чтения с диска, то фигня.
     
  • 1.70, Аноним (-), 19:32, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В итоге будет представлено работающее на уровне ядра Linux (в LessFS используется FUSE) высокопроизводительное блочное устройство, поддерживающее автоматическое объединение дубликатов данных.

    Единственная более-менее понятная и обнадеживающая новость.
    А смысл EPRD непонятен совершенно - чем оно отличается от обычной ФС с большим кешем?

     
  • 1.72, Аноним (72), 23:13, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давно ждал. Вот если grub еще научится ядро грузить из такого диска.
     
     
  • 2.74, Aleks Revo (ok), 02:16, 07/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос: зачем???
    Не проще ли ядро читать с обычного раздела, если чтение при загрузке всё равно идёт с диска?
    А запись в /boot так и вообще происходит раз в пятилетку...
     
  • 2.84, Аноним (-), 00:37, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Давно ждал. Вот если grub еще научится ядро грузить из такого диска.

    А в чем профит? Лучше уж /boot на ssd вынести.

     

  • 1.79, Аноним (79), 21:00, 07/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья навеяла.
     
     
  • 2.83, Аноним (-), 00:37, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Спасибо Adobe за это!
     
     
  • 3.87, тоже Аноним (ok), 14:17, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вопрос был про другой флеш - про флешку, которую Винды научились использовать как быстрый своп, чтобы ускорить загрузку системы.
    В Линуксе же есть возможность и вынести систему на сколь угодно быстрый носитель, и оптимизировать загрузку непосредственно, оставив в ней только необходимое. Это куда эффективнее, чем подпирание наследственных болезней "передовыми технологиями". Но, конечно, это не выглядит как привлекательный товар. Хотя бы потому, что это не товар.
     
     
  • 4.96, Michael Shigorin (ok), 18:44, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вопрос был про другой флеш - про флешку, которую Винды научились использовать
    > как быстрый своп, чтобы ускорить загрузку системы.

    Intel TurboMemory[1] в линуксе до сих пор не поддерживается (у меня под руками гиг такого флэша в X61t воткнутым приехал, всё не доходят выкинуть его, чтоб свои милли/микроамперы не жрал) -- поскольку интел сам потом понял бессмысленность всей затеи в корне.

    [1] http://www.thinkwiki.org/wiki/Intel®_Turbo_Memory_hard_drive_cache

     
  • 2.98, Алексей Поляков (?), 13:55, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно
    > как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья
    > навеяла.

    Это по-моему и в винде новой уже выпилили в связи с неудачностью изначальной идеи.
    На десктопе (что в винде, что в линуксе) для сколько-нибудь приличной производительности своп должен быть отключен.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру