Кто-нибудь знает как можно реализовать такое: использовать RAM диск как буфер для записи на жёсткий диск?
То есть, к примеру, есть RAМ диск на 2ГБ. Программа генерирует медленно файл размером 6ГБ. Хочется чтобы сперва файл писался в RAM-диск, а потом скопом сбрасывался на жёсткий диск. Но файл чтобы был непрерывным.
LinuxForum.Fans
RAM диск и большие файлы
Автор: Vascom
24 сообщений
1534 просмотров
Кто-нибудь знает как можно реализовать такое: использовать RAM диск как буфер для записи на жёсткий диск?
То есть, к примеру, есть RAМ диск на 2ГБ. Программа генерирует медленно файл размером 6ГБ. Хочется чтобы сперва файл писался в RAM-диск, а потом скопом сбрасывался на жёсткий диск. Но файл чтобы был непрерывным.
Ничего умнее как организовать на RAM очередь FIFO мне не приходит.
А как это сделать попроще? Может на bash.
оно так УЖЕ реализовано.То есть, к примеру, есть RAМ диск на 2ГБ. Программа генерирует медленно файл размером 6ГБ. Хочется чтобы сперва файл писался в RAM-диск, а потом скопом сбрасывался на жёсткий диск. Но файл чтобы был непрерывным.
Но вы конечно можете навелосипедить что-то типа этого:
1. создаём рамдиск, т.е. у меня так:
text
tmpfs /tmp tmpfs nodev,nosuid,size=700M 0 02. пишем туда файл
3. останавливаем запись в файл, вынимаем командой dd(UPD можно head(1) вместо dd) первые N байт файла, и добавляем в хвост файла на HDD
4. тоже командой dd копируем хвост в другой файл на tmpfs (UPD можно tail(1))
5. удаляем исходный файл из tmpfs
6. возобновляем запись уже в новый файл
Этот самый "хвост" можно сделать маленьким, тогда п4 будет очень быстрым.
А зачем это извращение нужно?
А как это сделать попроще? Может на bash.
[console]man 1 mkfifo[/console]
только я не уверен, что вам именно это нужно.
Ну вот остановить запись в файл я не могу. Если только останавливать работу программы, но тогда теряется весь смысл.
Да так, думал может это ускорит работу приложения, если жёсткий диск не будет постоянно дёргаться. Но, видимо, овчинка выделки не стоит и системный кеш и так нормально работает.
на самом деле можноНу вот остановить запись в файл я не могу.
1. остановить работу программы, типа как вы посылаете ей ^Z (suspend)
2. подменить ей файл назначения
3. продолжить исполнение
думал может это ускорит работу приложения
Нет. Проблема в том, что программа УЖЕ пишет в файл. А если она использует не буфферезированную запись, значит тому есть весомая причина. Если причин нет, используют буфферезированную запись, когда данные сначала поступают в буфер в RAM, и лишь когда их там накопится много, они пишуться на HDD.
ну только ессли программу пейсал криворукий быдлокодер. И то, в этом случае проще программу переделать, либо найти другую.Но, видимо, овчинка выделки не стоит
Программа проприетарная и профессиональная, другую найти нельзя.
А можно как-нибудь этим кешем в ОЗУ порулить? Просто оперативки тут много (есть машины с 288ГБ и 768ГБ). Пока пробую чисто в RAM диск писать, скоро будет видно есть прирост скорости или нет.
P.S. Соответственно файлы не 6ГБ как в примере, а 10-100ГБ.
AFAIK можно, но только из самой программы.А можно как-нибудь этим кешем в ОЗУ порулить?
В вашем случае возможно поможет костыль, в который будет писать ваша программа, и такой костыль лучше всего писать на сишке. На питоне/баше конечно в принципе тоже можно, но не думаю, что из этого будет какой-то выигрыш.
Костыль мне видится таким:
1. костыль создаёт named pipe с помощью mkfifo(3)
2. ваша программа пишет в этот named pipe
3. костыль время от времени вынимает по N байтов из пайпа, и кидает эти байты на HDD.
Ясно, спасибо за ответы.
и да, задача специфическая, её решение зависит от многих неизвестных. ИМХО проще самому написать костыль, который идеально вам подойдёт. Готовых решений вы вряд-ли найдёте.
Напоследок добавлю, что костыль обязательно должен делать sync, либо использовать НЕ буферизируюмую запись на HDD. Два кеша не имеют смысла.
Кто-нибудь знает как можно реализовать такое: использовать RAM диск как буфер для записи на жёсткий диск?
То есть, к примеру, есть RAМ диск на 2ГБ. Программа генерирует медленно файл размером 6ГБ. Хочется чтобы сперва файл писался в RAM-диск, а потом скопом сбрасывался на жёсткий диск. Но файл чтобы был непрерывным.
Что-то я ничего не понял. Файл и так сначала буферизуется в RAM сколько может. Всё это сильно напоминает популярный у конкурентов баян про swap в ram :) Что требуется - реализовать что-то типа транзакции с шансом undo?
Нет, транзакции и undo не нужны.
А вот сколько это "сколько сможет"?
А вот сколько это "сколько сможет"?
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Смотрите параметры, начинающиеся с dirty (dirty data - это данные, которые изменились в кеше, но еще не записаны на диск). Изменяя их, вы можете сделать то, что хотите, без костылей. Но, имхо, не стоит сильно увлекаться увеличением.
Нет, транзакции и undo не нужны.
А вот сколько это "сколько сможет"?
Ну тогда быстрее не будет, особенно если данные поступают медленно.
Про "сколько сможет" вам уже объяснили, но тут система и без доп настроек уже поступает достаточно разумно. Разве что - пишется на что-то совсем медленное, например на флешку usb2.
по дефолту оно всю память забивает AFAIK.А вот сколько это "сколько сможет"?
Ну не всю. У меня постоянно 100ГБ не используемые, ни под кеш, ни под буферы.
Гораздо быстрее сбрасывает на диск.
настройки надо подкрутить видимо. Очевидно дефолт для более меньших объёмов RAM.У меня постоянно 100ГБ не используемые
Хочется чтобы сперва файл писался в RAM-диск, а потом скопом сбрасывался на жёсткий диск.
не особо понял, а какова цель всего этого цирка?
Цель вот какова: программа работает и выводит результат на экран, при этом одновременно пишет данные в файл (данные гораздо больше, чем результат на экране). По результатам работы программы иногда приходится смотреть записанный файл, но результат требуется получить как можно раньше. Понятно, что запись данных тормозит работу программы.
Идеей было чтобы программа быстро отработала, а потом уже сбрасывала данные на жёсткий диск.
После теста выяснил, что выигрыш невелик: при работе с жёстким диском время выполнения было 4 часа 20 минут, а при работе с RAM диском 4 часа. При этом файл данных был 40ГБ.
Понятно, что запись данных тормозит работу программы.
нуда... уже объяснили, что не тормозит.... если конечно не сделать ничего странного вроде mount -o sync...
думал может быть цель была уменьшить фрагментацию файла...
После теста выяснил, что выигрыш невелик: при работе с жёстким диском время выполнения было 4 часа 20 минут, а при работе с RAM диском 4 часа.
можно списать на случайное отклонение….
Войдите или зарегистрируйтесь, чтобы ответить.
