Лучшие практики сохранения профиля Firefox на виртуальном диске

Question

Имея много оперативной памяти, я бы хотел использовать ее для ускорения работы браузера.

Цели:

1. Имейте профиль и кеш полностью в памяти, чтобы жесткий диск не использовался во время просмотра, а fsync не достигли реального жесткого диска или файловых систем.
2. В фоновом режиме продолжайте обновлять копию профиля жесткого диска, чтобы в случае внезапного отключения не более X минут просмотра было потеряно;
3. Сохраняйте резервные копии согласованными (без поврежденных баз данных sqlite и т.д.)

Т.е. обменять некоторую свободную память и некоторую свежесть сеанса просмотра в случае сбоя на скорость.

Как организовать такую схему?

Моя текущая идея такова:

1. Используйте zram для создания виртуального диска; modprobe zram ;
2. Создайте на нем том LVM losetup /dev/zram0 /dev/loop1; pvcreate /dev/loop1; ...; mke2fs -t ext4 -O ^has_journal /dev/mapper/ffvg-ffvol ;
3. Разместите профиль Firefox на этом томе;
4. Периодически (каждые N минут) создайте снимок LVM и сделайте его резервную копию на жесткий диск, затем снимите снимок.

Это (особенно часть LVM) выглядит немного тяжелым для этой задачи. Есть ли лучшие / более устоявшиеся / более простые способы для этого?

Answer 1

Настроил том для Firefox в соответствии с рассматриваемой идеей.

• При загрузке создаются два устройства Zram. Содержимое тома HDD копируется на первый. Второй используется в качестве устройства копирования при записи для снимков;
• Каталог профиля Firefox связан с томом, хранящимся в zram0.
• Периодически скрипт (ниже) создает снимок устройства в памяти (используя zram1 в качестве копии при записи), снимок тома HDD и копирует снимок памяти на том HDD.

Каждое обновление занимает около 10 секунд (в случае небольшого количества изменений); полное обновление составляет 40 секунд.

Обновить скрипт:

#!/bin/bash

set -e

SOURCE_DEVICE=/dev/zram0
COW_DEVICE=/dev/zram1
SOURCE_SNAPSHOT_NAME=ffsnap

DESTINATION_VG=cryptie3
DESTINATION_VOL=ff

HASH_FILE=/tmp/ff.md5


MS=$(blockdev --getsize "$SOURCE_DEVICE")
WS=$(blockdev --getsize "$COW_DEVICE")
MN=$(printf '%d:%d' `stat -c '0x%t 0x%T' "$SOURCE_DEVICE"`)
WN=$(printf '%d:%d' `stat -c '0x%t 0x%T' "$COW_DEVICE"`)

dmsetup create $SOURCE_SNAPSHOT_NAME --table "0 $MS snapshot $MN $WN N 8"
trap "dmsetup remove --force --retry $SOURCE_SNAPSHOT_NAME" EXIT

T=$(date "+%s")

lvcreate $DESTINATION_VG/$DESTINATION_VOL --snapshot --name ${DESTINATION_VOL}_$T -L 100M

# You can just use "cat /dev/mapper/$SOURCE_SNAPSHOT_NAME > /dev/mapper/$DESTINATION_VG-$DESTINATION_VOL" here if you don't want to use hashed_update

if [ -e "$HASH_FILE" ]; then
    /usr/local/bin/hashed_update /dev/mapper/$SOURCE_SNAPSHOT_NAME            "$HASH_FILE"  \
                                 /dev/mapper/$DESTINATION_VG-$DESTINATION_VOL "${HASH_FILE}".new 65536
    mv "${HASH_FILE}".new "$HASH_FILE"
else
    /usr/local/bin/hashed_update /dev/mapper/$SOURCE_SNAPSHOT_NAME NULL   \
                                 /dev/mapper/$DESTINATION_VG-$DESTINATION_VOL "$HASH_FILE" 65536
fi

lvremove --force ${DESTINATION_VG}/${DESTINATION_VOL}_$T

hashed_update находится здесь: https://github.com/vi/hashed_update

Некоторое обновление: 1. Не стоит монтировать SOURCE_DEVICE хотя это snapshot-origin , а не напрямую; 2. Теперь я использую ручное управление снимками назначения с постоянной зоной CoW, используя dmsetup вместо повторяющихся lvcreate/lvremove.

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