Просветите по поводу рамдисков
Просветите по поводу рамдисков
Нужно соорудить такое чудище:
Многослойная фс (overlayfs?) в отдельно взятой папке.
Нижний слой - ro > из него данные "переносятся" в рамдиск (какой кстати лучше?) > сверху - rw слой.
В идеале:
Данные из -rw слоя, должны сбрасываться на HDD при размонтировании всего этого "дела" и подгружаться в рамдиск при следующем монтировании.
В общем, сам я не смог разобраться.
Уповаю на помощь форумчан.
Многослойная фс (overlayfs?) в отдельно взятой папке.
Нижний слой - ro > из него данные "переносятся" в рамдиск (какой кстати лучше?) > сверху - rw слой.
В идеале:
Данные из -rw слоя, должны сбрасываться на HDD при размонтировании всего этого "дела" и подгружаться в рамдиск при следующем монтировании.
В общем, сам я не смог разобраться.
Уповаю на помощь форумчан.
Re: Просветите по поводу рамдисков
MagOS вам в помощь.
-
- Сообщения: 71
- Зарегистрирован: 21 авг 2015, 13:45
- Откуда: Салават, Башкортостан, РФ
- Контактная информация:
Re: Просветите по поводу рамдисков
Затрудняюсь определить, тема похожая по сути или только внешне... но спрошу таки здесь.
Специфическая задача. Редкая, соглашусь.
Имеем: один или несколько заполненных контентом носителей, которые или совсем Read-ONLY (CD-ROM, DVD-ROM, заблокированные на запись, недоубитые флешки и флэш-карточки), или физически стереть можно, но нежелательно (HDD с разной информацией, ЧАСТЬ которой публикации не подлежит).
Надо: подключить такой носитель в систему таким хитрым образом, чтобы оказались видны ТОЛЬКО конкретные каталоги. Или файлы, типы файлов -- по некоему признаку, фильтру или просто списку. Чтобы в точке монтирования и глубже не путались прочие файлы, которые отображать не следует. И чтобы этот фильтр ЗАПОМИНАЛСЯ в каком-то кэше для последующего подключения и размапливания этого же носителя тем же образом.
Для чего это может пригодиться?
Медиа-сервер или домашний, офисный NAS. После полусмерти в смартфонах у меня уже несколько полуживых uSDHC-карточек, на которых остались музыка, видео, фотографии. Читать можно, перезаписать, стереть, что-то изменить уже нельзя. Есть и диски оптические, которые местами не читаются и начинают тормозить и шоркать в приводе (HDD ведь исключают битые сектора из таблиц?). Или на оптические носители сбрасывались не только альбомы медиафайлов, а еще и архивы софта, документов, до кучи. Так вот -- необходимо СПРЯТАТЬ лишнее с этих носителей (каталоги приложений, логи, документы, скриншоты, временные файлы) -- если уж их нельзя стереть. Чтобы не засорять лишними объектами выбор медиафайлов, скажем, со смартфона или смарт-телевизора, плеера. Возможно даже переименовать файлы на проходе, перевести название на другой язык или сменить кодировку имени (кракозябры!) В общем, добавить промежуточный слой файловой системы, реорганизующий исходное дерево объектов подключенного носителя. Как это смонтировать вручную, я себе примерно представляю... но желательно этот слепок схемы монтирования каждого носителя сохранять на будущее и применять автоматом.
Например, пару таких раненых карточек на 32GB у меня жует магнитола в машине. Да, долго ищет среди андроидовских служебных каталогов музыку... находит альбомы -- играет... Но меж делом там попадаются и рингтоны нафиг не нужные, а среди фоток и скриншоты, фотки документов и аппаратуры, которую я иногда монтирую и налаживаю. А при переключении носителя сканирование начинается заново -- и пока найдет что-то, иногда уже доехать можно
Не встречалось ли кому-то подобной идеи или решения, эдакой прокси-FS?
Специфическая задача. Редкая, соглашусь.
Имеем: один или несколько заполненных контентом носителей, которые или совсем Read-ONLY (CD-ROM, DVD-ROM, заблокированные на запись, недоубитые флешки и флэш-карточки), или физически стереть можно, но нежелательно (HDD с разной информацией, ЧАСТЬ которой публикации не подлежит).
Надо: подключить такой носитель в систему таким хитрым образом, чтобы оказались видны ТОЛЬКО конкретные каталоги. Или файлы, типы файлов -- по некоему признаку, фильтру или просто списку. Чтобы в точке монтирования и глубже не путались прочие файлы, которые отображать не следует. И чтобы этот фильтр ЗАПОМИНАЛСЯ в каком-то кэше для последующего подключения и размапливания этого же носителя тем же образом.
Для чего это может пригодиться?
Медиа-сервер или домашний, офисный NAS. После полусмерти в смартфонах у меня уже несколько полуживых uSDHC-карточек, на которых остались музыка, видео, фотографии. Читать можно, перезаписать, стереть, что-то изменить уже нельзя. Есть и диски оптические, которые местами не читаются и начинают тормозить и шоркать в приводе (HDD ведь исключают битые сектора из таблиц?). Или на оптические носители сбрасывались не только альбомы медиафайлов, а еще и архивы софта, документов, до кучи. Так вот -- необходимо СПРЯТАТЬ лишнее с этих носителей (каталоги приложений, логи, документы, скриншоты, временные файлы) -- если уж их нельзя стереть. Чтобы не засорять лишними объектами выбор медиафайлов, скажем, со смартфона или смарт-телевизора, плеера. Возможно даже переименовать файлы на проходе, перевести название на другой язык или сменить кодировку имени (кракозябры!) В общем, добавить промежуточный слой файловой системы, реорганизующий исходное дерево объектов подключенного носителя. Как это смонтировать вручную, я себе примерно представляю... но желательно этот слепок схемы монтирования каждого носителя сохранять на будущее и применять автоматом.
Например, пару таких раненых карточек на 32GB у меня жует магнитола в машине. Да, долго ищет среди андроидовских служебных каталогов музыку... находит альбомы -- играет... Но меж делом там попадаются и рингтоны нафиг не нужные, а среди фоток и скриншоты, фотки документов и аппаратуры, которую я иногда монтирую и налаживаю. А при переключении носителя сканирование начинается заново -- и пока найдет что-то, иногда уже доехать можно
Не встречалось ли кому-то подобной идеи или решения, эдакой прокси-FS?
Re: Просветите по поводу рамдисков
systemd.mount и aufs.
Re: Просветите по поводу рамдисков
Ну, мне "это" нужно только в одной папке и для одной программы, а не для всей системы...MagOS вам в помощь.
Буду рад, если у кого-то найдется свободная минутка - объяснить мне все это дело.
Re: Просветите по поводу рамдисков
Набрал в поисковике: рам диск линукс
Выдало: Перенос Google Chrome на RAM-диск в Linux https://habrahabr.ru/post/205158/
Вроде похоже по требованиям.
Выдало: Перенос Google Chrome на RAM-диск в Linux https://habrahabr.ru/post/205158/
Вроде похоже по требованиям.
Re: Просветите по поводу рамдисков
trs
Ну, да - посыл в нужном направлении...
Тем не менее, мне нужно понять - как направлять данные в ramдиск (а не просто монтировать туда папку).
Ну, да - посыл в нужном направлении...
Тем не менее, мне нужно понять - как направлять данные в ramдиск (а не просто монтировать туда папку).
Re: Просветите по поводу рамдисков
рамдиск сам по себе малоинтересен на фоне tmpfs т.к. она умеет занимать в памяти столько, сколько нужно и даже свопиться. А делается просто - папка переименовывается, монтируется с правильным именем в tmpfs и ее содержимое копируется уже на tmpfs. И дальше все туда попадает.
У нас так /home монтируется в live-режиме.
У нас так /home монтируется в live-режиме.
Re: Просветите по поводу рамдисков
Во что переименовывается то?папка переименовывается, монтируется с правильным именем в tmpfs
Re: Просветите по поводу рамдисков
Хоть во что. Это нужно чтоб создать папку с таким же именем, смонтированную в tmpfs
Re: Просветите по поводу рамдисков
А зачем копировать в tmpfs? Совместить нужным каталогом с помощью aufs не лучше?keleg писал(а):рамдиск сам по себе малоинтересен на фоне tmpfs т.к. она умеет занимать в памяти столько, сколько нужно и даже свопиться. А делается просто - папка переименовывается, монтируется с правильным именем в tmpfs и ее содержимое копируется уже на tmpfs. И дальше все туда попадает.
У нас так /home монтируется в live-режиме.
У меня так /home монтируется. Часть данных пользователя лежит на SSD, которые должны очень быстро грузиться (те же настройки KDE), остальное лежит на HDD (точнее на зеркальном фейк рейде.). Каталог с SSD в aufs монтируется в ридонли. А все изменения падают на HDD.
Никто не мешает каталог под изменяемые данные разместить в tmpfs.
Re: Просветите по поводу рамдисков
А затем, что бы увеличить скорость чтения, а не только скорость записи.А зачем копировать в tmpfs? Совместить нужным каталогом с помощью aufs не лучше?
P.S. Вариант "скрестить" SSD с HDD довольно интересен.
Re: Просветите по поводу рамдисков
Есть такая штука, как кэш файловой системы, где данные остаются после первого чтения. Это примерно тот же tmpfs, но копирование происходит по мере необходимости и выгрузка в файл подкачки для него не требуется — на всём этом экономится время. Таким образом по вышеприведённой мною ссылке самая полезная с точки зрения "ускорения" информация — комментарий, что это всё от лукавого.
В live-режиме условия иные, доступного для записи носителя нет, приходится его эмулировать.
В live-режиме условия иные, доступного для записи носителя нет, приходится его эмулировать.
Re: Просветите по поводу рамдисков
А можно подробнее?Есть такая штука, как кэш файловой системы, где данные остаются после первого чтения.
Жрет ОЗУ? Есть риск потери файлов?Это примерно тот же tmpfs, но копирование происходит по мере необходимости и выгрузка в файл подкачки для него не требуется — на всём этом экономится время.
Это что такую скорость смогло показать?# hdparm -t /dev/zd0
/dev/zd0:
Timing buffered disk reads: 2048 MB in 0.71 seconds = 2875.79 MB/sec
Re: Просветите по поводу рамдисков
Кэш ФС является частью ядра ОС. Наберите команду free. При операциях чтения с накопителей данные сначала помещаются в кеш, а после копируются в пользовательское приложение. ОЗУ жрёт аж за ушами трещит пока есть свободное место, данные из кеша не удаляются. Таким образом если читать файл повторно, то к диску обращений не будет — получается тот же "рамдиск". Когда потребуется память, содержимое кеша "выбрасывается", то есть память просто освобождается. Диск на tmpfs и т.п. при этом нужно будет выгрузить в swap, что бы данные не пропали. При операциях записи рамдиск в каких-то случаях может работать быстрее, особенно в синтетических тестах, поскольку на традиционный диск в это время ничего не пишется — и легко потеряется при аварии. Кроме того, если сохранять данные из рамдиска при выключении ОС, то будет определённая пауза, а из кеша данные будут записаны прозрачно, заранее, когда ОС найдёт для того время. Получается такой парадокс: ОС может писать на диск хоть 100 раз, но пользователь это никак не заметит, поскольку будет занят чтением статьи о пользе рамдисков. Они где-то дают выигрыш, но в большинстве случаев ОС управляет ресурсами лучше, чем её пользователь.
А скорость — измеряйте сами, ещё не то покажет. Выше я создал том (volume) на той "самой тормознутой и жрущей ОЗУ" ZFS — аналог обычного диска, можно отформатировать как угодно. Как раз за счёт кеширования повторные результаты сильно быстрее первого измерения. Так же и с обычными файлами:
А скорость — измеряйте сами, ещё не то покажет. Выше я создал том (volume) на той "самой тормознутой и жрущей ОЗУ" ZFS — аналог обычного диска, можно отформатировать как угодно. Как раз за счёт кеширования повторные результаты сильно быстрее первого измерения. Так же и с обычными файлами:
Код: Выделить всё
$ dd of=/dev/null if=ROSA.FRESH.LXQT.R6.i586.iso bs=1M
1250+0 записей получено
1250+0 записей отправлено
скопировано 1310720000 байт (1.3 GB), 7.33693 c, 179 MB/c
$ dd of=/dev/null if=ROSA.FRESH.LXQT.R6.i586.iso bs=1M
1250+0 записей получено
1250+0 записей отправлено
скопировано 1310720000 байт (1.3 GB), 0.295468 c, 4.4 GB/c