Просветите по поводу рамдисков

[Vochatrak]

Нужно соорудить такое чудище:
Многослойная фс (overlayfs?) в отдельно взятой папке.
Нижний слой - ro > из него данные "переносятся" в рамдиск (какой кстати лучше?) > сверху - rw слой.

В идеале:
Данные из -rw слоя, должны сбрасываться на HDD при размонтировании всего этого "дела" и подгружаться в рамдиск при следующем монтировании.

В общем, сам я не смог разобраться.
Уповаю на помощь форумчан.

[keleg]

MagOS вам в помощь.

[Ansy]

Затрудняюсь определить, тема похожая по сути или только внешне... но спрошу таки здесь.

Специфическая задача. Редкая, соглашусь.
Имеем: один или несколько заполненных контентом носителей, которые или совсем Read-ONLY (CD-ROM, DVD-ROM, заблокированные на запись, недоубитые флешки и флэш-карточки), или физически стереть можно, но нежелательно (HDD с разной информацией, ЧАСТЬ которой публикации не подлежит).

Надо: подключить такой носитель в систему таким хитрым образом, чтобы оказались видны ТОЛЬКО конкретные каталоги. Или файлы, типы файлов -- по некоему признаку, фильтру или просто списку. Чтобы в точке монтирования и глубже не путались прочие файлы, которые отображать не следует. И чтобы этот фильтр ЗАПОМИНАЛСЯ в каком-то кэше для последующего подключения и размапливания этого же носителя тем же образом.

Для чего это может пригодиться?
Медиа-сервер или домашний, офисный NAS. После полусмерти в смартфонах у меня уже несколько полуживых uSDHC-карточек, на которых остались музыка, видео, фотографии. Читать можно, перезаписать, стереть, что-то изменить уже нельзя. Есть и диски оптические, которые местами не читаются и начинают тормозить и шоркать в приводе (HDD ведь исключают битые сектора из таблиц?). Или на оптические носители сбрасывались не только альбомы медиафайлов, а еще и архивы софта, документов, до кучи. Так вот -- необходимо СПРЯТАТЬ лишнее с этих носителей (каталоги приложений, логи, документы, скриншоты, временные файлы) -- если уж их нельзя стереть. Чтобы не засорять лишними объектами выбор медиафайлов, скажем, со смартфона или смарт-телевизора, плеера. Возможно даже переименовать файлы на проходе, перевести название на другой язык или сменить кодировку имени (кракозябры!) В общем, добавить промежуточный слой файловой системы, реорганизующий исходное дерево объектов подключенного носителя. Как это смонтировать вручную, я себе примерно представляю... но желательно этот слепок схемы монтирования каждого носителя сохранять на будущее и применять автоматом.

Например, пару таких раненых карточек на 32GB у меня жует магнитола в машине. Да, долго ищет среди андроидовских служебных каталогов музыку... находит альбомы -- играет... Но меж делом там попадаются и рингтоны нафиг не нужные, а среди фоток и скриншоты, фотки документов и аппаратуры, которую я иногда монтирую и налаживаю. А при переключении носителя сканирование начинается заново -- и пока найдет что-то, иногда уже доехать можно

Не встречалось ли кому-то подобной идеи или решения, эдакой прокси-FS?

[notauser]

systemd.mount и aufs.

[Vochatrak]

MagOS вам в помощь.

Ну, мне "это" нужно только в одной папке и для одной программы, а не для всей системы...
Буду рад, если у кого-то найдется свободная минутка - объяснить мне все это дело.

[trs]

Набрал в поисковике: рам диск линукс
Выдало: Перенос Google Chrome на RAM-диск в Linux https://habrahabr.ru/post/205158/
Вроде похоже по требованиям.

[Vochatrak]

trs
Ну, да - посыл в нужном направлении...
Тем не менее, мне нужно понять - как направлять данные в ramдиск (а не просто монтировать туда папку).

[keleg]

рамдиск сам по себе малоинтересен на фоне tmpfs т.к. она умеет занимать в памяти столько, сколько нужно и даже свопиться. А делается просто - папка переименовывается, монтируется с правильным именем в tmpfs и ее содержимое копируется уже на tmpfs. И дальше все туда попадает.
У нас так /home монтируется в live-режиме.

[Vochatrak]

папка переименовывается, монтируется с правильным именем в tmpfs

Во что переименовывается то?

[keleg]

Хоть во что. Это нужно чтоб создать папку с таким же именем, смонтированную в tmpfs

[Yamah]

рамдиск сам по себе малоинтересен на фоне tmpfs т.к. она умеет занимать в памяти столько, сколько нужно и даже свопиться. А делается просто - папка переименовывается, монтируется с правильным именем в tmpfs и ее содержимое копируется уже на tmpfs. И дальше все туда попадает.
У нас так /home монтируется в live-режиме.

А зачем копировать в tmpfs? Совместить нужным каталогом с помощью aufs не лучше?

У меня так /home монтируется. Часть данных пользователя лежит на SSD, которые должны очень быстро грузиться (те же настройки KDE), остальное лежит на HDD (точнее на зеркальном фейк рейде.). Каталог с SSD в aufs монтируется в ридонли. А все изменения падают на HDD.

Никто не мешает каталог под изменяемые данные разместить в tmpfs.

[Vochatrak]

А зачем копировать в tmpfs? Совместить нужным каталогом с помощью aufs не лучше?

А затем, что бы увеличить скорость чтения, а не только скорость записи.

P.S. Вариант "скрестить" SSD с HDD довольно интересен.

[trs]

Есть такая штука, как кэш файловой системы, где данные остаются после первого чтения. Это примерно тот же tmpfs, но копирование происходит по мере необходимости и выгрузка в файл подкачки для него не требуется — на всём этом экономится время. Таким образом по вышеприведённой мною ссылке самая полезная с точки зрения "ускорения" информация — комментарий, что это всё от лукавого.

В live-режиме условия иные, доступного для записи носителя нет, приходится его эмулировать.

Код: Выделить всё

# hdparm -t /dev/zd0 

/dev/zd0:
 Timing buffered disk reads: 2048 MB in  2.28 seconds = 897.84 MB/sec

# hdparm -t /dev/zd0 

/dev/zd0:
 Timing buffered disk reads: 2048 MB in  0.71 seconds = 2875.79 MB/sec

[Vochatrak]

Есть такая штука, как кэш файловой системы, где данные остаются после первого чтения.

А можно подробнее?

Это примерно тот же tmpfs, но копирование происходит по мере необходимости и выгрузка в файл подкачки для него не требуется — на всём этом экономится время.

Жрет ОЗУ? Есть риск потери файлов?

# hdparm -t /dev/zd0
/dev/zd0:
Timing buffered disk reads: 2048 MB in 0.71 seconds = 2875.79 MB/sec

Это что такую скорость смогло показать?

[trs]

Кэш ФС является частью ядра ОС. Наберите команду free. При операциях чтения с накопителей данные сначала помещаются в кеш, а после копируются в пользовательское приложение. ОЗУ жрёт аж за ушами трещит пока есть свободное место, данные из кеша не удаляются. Таким образом если читать файл повторно, то к диску обращений не будет — получается тот же "рамдиск". Когда потребуется память, содержимое кеша "выбрасывается", то есть память просто освобождается. Диск на tmpfs и т.п. при этом нужно будет выгрузить в swap, что бы данные не пропали. При операциях записи рамдиск в каких-то случаях может работать быстрее, особенно в синтетических тестах, поскольку на традиционный диск в это время ничего не пишется — и легко потеряется при аварии. Кроме того, если сохранять данные из рамдиска при выключении ОС, то будет определённая пауза, а из кеша данные будут записаны прозрачно, заранее, когда ОС найдёт для того время. Получается такой парадокс: ОС может писать на диск хоть 100 раз, но пользователь это никак не заметит, поскольку будет занят чтением статьи о пользе рамдисков. Они где-то дают выигрыш, но в большинстве случаев ОС управляет ресурсами лучше, чем её пользователь.

А скорость — измеряйте сами, ещё не то покажет. Выше я создал том (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