Файловая система, удобная И для временных файлов

Я выделил букву "И", чтобы подчеркнуть, что ФС будет использоваться не только для временных файлов. Так что рамдиск или tmpfs отпадают. Нужна ФС общего назначения, которая на жёстком диске создаётся. Но при это она (или её драйвер, или вообще настройки линукса, я не знаю, от кого из них это зависит) должны быть оптимизированы для таких ситуаций:

1. Создаётся файл размером 512 байт. Через полминуты (максимум) другая прога читает его и стирает.
2. Создаётся файл размером несколько мегабайт, но почти сразу (максимум через пару секунд) стирается.

Достаточно ли "разумен" Линукс, чтобы в таких ситуациях вообще ничего на диск не записывать? В винде такое есть:

Файлы, созданные с атрибутом FILE_ATTRIBUTE_TEMPORARY и флагом FILE_FLAG_DELETE_ON_CLOSE размещаются в ОЗУ и записываются на жёсткий диск только если системе не хватает оперативной памяти.

Подход "как в оффтопике" провальный.
Не надо подстраивать линукс под то как вам привычно. В линуксе намного больше вариантов подстроить ту или иную задачу под себя.
Учитесь правильно соображать и полностью задачу огласите, быстрее подскажут приемлемое решение.
По поводу fs - их много, - ext/2/3/4, reiserfs, btrfs, xfs, jfs, zfs... дерзайте. Да zfs например умеет read-on-write - оффтопику такого и не снилось.

"Пятисотый⇓" написал:

Достаточно ли "разумен" Линукс, чтобы в таких ситуациях вообще ничего на диск не записывать? В винде такое есть:

Очень похоже на ZRAM FS
Зы: В ней память используется динамически в зависимости от заполнения.
А все такое как сохранение на жесткий диск, можно осуществить программно.

zenon написал:

Да zfs например умеет read-on-write - оффтопику такого и не снилось.

А что это за технология такая?

"fragment⇓" написал:

А что это за технология такая?

Ошибочка`с - ZFS: Copy-on-Write filesystem.

свои 5 копеек:
Пятисотый, FHS говорит, счто такие файлы должны хранится в /tmp, а уж как они будут представлены дело ОС и/или админа.
если хочется какого-то извращения, то рассказывай, зачем...

"zenon⇓" написал:

Да zfs например умеет read-on-write - оффтопику такого и не снилось.

наверно, всё же copy-on-wright =)

Про оффтопик я написал только для того, чтобы объяснить, что примерно мне нужно. А задача очень простая: надо обмениваться данными между программами с помощью временных файлов. Другого варианта, к сожалению, просто нет (одна из программ - не моя, и она имеет закрытый код). По хорошему, надо просто сделать рамдиск объёмом несколько мегабайт. Но я решил сначала узнать про альтернативные варианты. А вдруг есть способ без лишних телодвижений?

"Пятисотый⇓" написал:

Про оффтопик я написал только для того, чтобы объяснить, что примерно мне нужно. А задача очень простая: надо обмениваться данными между программами с помощью временных файлов. Другого варианта, к сожалению, просто нет (одна из программ - не моя, и она имеет закрытый код). По хорошему, надо просто сделать рамдиск объёмом несколько мегабайт. Но я решил сначала узнать про альтернативные варианты. А вдруг есть способ без лишних телодвижений?

дык подсунь второй программе трубу... и делов то... или ей нужно seek'асться?
или создавай файл в /tmp. а дальше не особо твоё дело...

Fat-Zer написал:

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

Если б всё было так просто - я бы не заморачивался. Если я упомянул винду - это не значит, что я полный ноль в линуксе.

или ей нужно seek'асться?

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

или создавай файл в /tmp. а дальше не особо твоё дело...

В смысле? Какая разница, где создавать, если физически это тот же жёсткий диск с той же ФС (например, ext3)?

По теме: почитал в википедии об XFS. Складывается впечатление, что там многое оптимизированно, в том числе и сценарии, похожие на мой. Есть тут спецы по XFS? Насколько она надёжна? Может, она подходит под мои нужды?

Пятисотый написал:

Про оффтопик я написал только для того, чтобы объяснить, что примерно мне нужно. А задача очень простая: надо обмениваться данными между программами с помощью временных файлов.
.....
Не знаю, что Вы имели в виду, но этой программе надо реальный файл.

Первое правило Линукса - всё есть файл. И для программного обмена информацией между двумя программами через файловую систему можно организовать pipe между этими программами. Одна программа в него пишет, другая - читает. И никакой специальной файловой системы для этого не требуется.

Ну и не совсем понятно - что есть "реальный" файл. Почему нельзя использовать mkfifo /path/to/real/file и писать в него из своей программы? А чужая программа из него прекрасно прочитает. или наоборот...

"Пятисотый⇓" написал:

Не знаю, что Вы имели в виду

выполняет системный вызов lseek()

"Пятисотый⇓" написал:

но этой программе надо реальный файл.

зачем? она что ли проверяет stat'ом, что это? или открывает его несколько раз? есть ещё конечно несколько вещей, которые с трубой не получатся... но попробовать стоит...

"Пятисотый⇓" написал:

Это всё равно как если бы я спросил, где купить оленину, а Вы бы начали грузить про вегетарианство.

сначала вы спросили, где купить дохлого ежа, теперь оказалось, что нужно просто мясо и на него вы решили пустить ежа... до того, что же такое «оленина» мы ещё не дошли...

"Пятисотый⇓" написал:

В смысле? Какая разница, где создавать, если физически это тот же жёсткий диск с той же ФС (например, ext3)?

это так... решение в стиле «смириться и забыть».... можно не воспринимать всерьёз... просто зачастую в /tmp монтируют tmpfs...
вообще говоря, даже обычный файл может не попасть на диск в зависимости от реального времени жизни, настроек сброса буферов итп... [надо проверить]

"Пятисотый⇓" написал:

По теме: почитал в википедии об XFS. Складывается впечатление, что там многое оптимизированно, в том числе и сценарии, похожие на мой. Есть тут спецы по XFS? Насколько она надёжна? Может, она подходит под мои нужды?

чисто из интереса, что же натолкнуло вас на такие мысли?

на уровне ФС нечто такое искать бесполезно, ИМХО.
на уровне буферов устройств, скорей всего, слишком поздно (хотя может и есть какой-то механизм отмены сброса)...
если что-то и будет подходящее, то надо копать в сторону решения на уровне vfs и кешей файлов....

отсюда вертится два варианта:
1) как-то задать индивидуальное для процесса или дескриптора время сброса грязных буферов (аналогичное /proc/sys/vm/dirty_writeback_centisecs) [может не сработать]
2) вроде, можно как-то хитро за'mmap'ить файл, но пока не скажу точно как... [может такого и не быть]

Пятисотый написал:

Про оффтопик я написал только для того, чтобы объяснить, что примерно мне нужно. А задача очень простая: надо обмениваться данными между программами с помощью временных файлов. Другого варианта, к сожалению, просто нет (одна из программ - не моя, и она имеет закрытый код). По хорошему, надо просто сделать рамдиск объёмом несколько мегабайт. Но я решил сначала узнать про альтернативные варианты. А вдруг есть способ без лишних телодвижений?

Посмотрите RamFS, tmpfs.

Cruiser78 написал:

Первое правило Линукса - всё есть файл.

Этого никто и не оспаривает. Однако отсюда не следует, что любые операции с файлами можно заменить пайпами.

И для программного обмена информацией между двумя программами через файловую систему можно организовать pipe между этими программами. Одна программа в него пишет, другая - читает. И никакой специальной файловой системы для этого не требуется.

Коммерческая проприетарная графическая программа на Джаве. Документированных способов скормить ей файл два:
1. Открываем меню "Файл", потом "Открыть...", затем два раза щёлкаем по значку искомомого файла;
2. Перетаскиваем значок файла мышкой в окно этой проги. Скорее всего, именно этот способ я и буду автоматизировать.
Внимание, вопрос: как организовать пайп?

Ну и не совсем понятно - что есть "реальный" файл. Почему нельзя использовать mkfifo /path/to/real/file и писать в него из своей программы? А чужая программа из него прекрасно прочитает. или наоборот...

Если уж что-то организовывать, то RamFS. Я хотел найти способ проще, а в результате усложнил себе жизнь. ССЗБ.

Fat-Zer написал:

сначала вы спросили, где купить дохлого ежа, теперь оказалось, что нужно просто мясо и на него вы решили пустить ежа... до того, что же такое «оленина» мы ещё не дошли...

А Вам не приходило в голову, что это не из-за того, что я такой безграмотный? Да я, может быть, зоолог. И прекрасно знаю о существовании многих других зверей, кроме ежей. Вот только я ещё знаю, где живу. И знаю, что в этой тундре можно только ежей найти. Если повезёт, можно наткнуться на вмёрзшую в толщу льда тушу мамонта. А Вы мне про ананасы и рябчиков расписываете... Да я верю, верю, что они хороши. Но здесь из деликатесов только труп беглого зэка.

"Пятисотый⇓" написал:

По теме: почитал в википедии об XFS. Складывается впечатление, что там многое оптимизированно, в том числе и сценарии, похожие на мой. Есть тут спецы по XFS? Насколько она надёжна? Может, она подходит под мои нужды?

чисто из интереса, что же натолкнуло вас на такие мысли?

Статья в русскоязычной Википедии. Напрямую там ничего такого не говорится, иначе бы я давно закрыл тему. Но очень много там оптимизаций, в том числе касающихся мелких файлов. А вдруг они оптимизировали и короткоживущие файлы?

"Пятисотый⇓" написал:

Если уж что-то организовывать, то RamFS.

RamFS отличется от tmpfs только тем, что её размер нельзя ограничить и тем, что она никогда не будет свапиться... от простого пользователя использовать её !опасно!.

"Fat-Zer⇓" написал:

отсюда вертится два варианта:
1) как-то задать индивидуальное для процесса или дескриптора время сброса грязных буферов (аналогичное /proc/sys/vm/dirty_writeback_centisecs) [может не сработать]
2) вроде, можно как-то хитро за'mmap'ить файл, но пока не скажу точно как... [может такого и не быть]

оба способа - чистой воды больная фантазия...
1) - т.к. /proc/sys/vm/dirty_writeback_centisecs просто задаёт таймаут демону и на попроцесном режиме его ни как не задать
2) - меньше уверен, что бред, но скорей всего сиё просто невозможно....

"Fat-Zer⇓" написал:

на уровне ФС нечто такое искать бесполезно, ИМХО.

напротив, создание такого атрибута гипотетически возможно... правда будет сложность с их хранением в каталоге...

"Пятисотый⇓" написал:

Внимание, вопрос: как организовать пайп?

mkpipe /tmp/my_pipe.ext # лучше нужное разрешение для файла указать...
cat file >/tmp/my_pipe.ext
перетащить /tmp/my_pipe в программу/открыть в ней... т.к. java, то скорей всего не заработает... наверняка попробует за''mmap'ить файл... была бы консольная утилитка 3-ей стороны или плюсы, то шанс был бы больше...

"Пятисотый⇓" написал:

А Вам не приходило в голову, что это не из-за того, что я такой безграмотный? Да я, может быть, зоолог. И прекрасно знаю о существовании многих других зверей, кроме ежей. Вот только я ещё знаю, где живу. И знаю, что в этой тундре можно только ежей найти. Если повезёт, можно наткнуться на вмёрзшую в толщу льда тушу мамонта. А Вы мне про ананасы и рябчиков расписываете... Да я верю, верю, что они хороши. Но здесь из деликатесов только труп беглого зэка.

пора завязывать с метафорами... >_<

"Пятисотый⇓" написал:

Статья в русскоязычной Википедии. Напрямую там ничего такого не говорится, иначе бы я давно закрыл тему. Но очень много там оптимизаций, в том числе касающихся мелких файлов. А вдруг они оптимизировали и короткоживущие файлы?

просто мелкие файлы, каталоги и симлинки могут хранится прямо в дескрипторе... это экономит место и время только для файлом < 256 байт... ЕМНИП такое в ext4 не сделали...
для файлов < 3К больше оптимизирована reiserfs. экономит место (и время, при их массовом чтении)
традиционно, она считается оптимизированной под очень большие каталоги (значительно, до появления ext4) и очень большие файлы.
новомодное масло и zfs это конечно отдельные темы...

ЗЫ: вообще, этот перфекционизм прироста в скорости не даст... [требует проверки] если бы речь шла хотя бы о десятках-сотнях мегабайт и многих файлах, то может и стоило бы задуматься... всё это только немного уменьшится использование диска...
ЗЗЫ: ещё важный вопрос: это для себя или для кого-то делаете? если первое, то тогда смонтировать весь /tmp в tmpfs и забыть... аьтернатив особых не вижу... если второе, то просто кидать временные файлы в /tmp и рядом приписать, что «если смонтировать tmpfs на /tmp, то будет быстрее».

Я не вникал в обсуждение, но вообще создать файл в памяти возможно,
man fmemopen.

Пётр.

ЗЫ: вообще, этот перфекционизм прироста в скорости не даст... [требует проверки] если бы речь шла хотя бы о десятках-сотнях мегабайт и многих файлах, то может и стоило бы задуматься... всё это только немного уменьшится использование диска...

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

ЗЗЫ: ещё важный вопрос: это для себя или для кого-то делаете?

Для себя.

если первое, то тогда смонтировать весь /tmp в tmpfs и забыть...

А ларчик, как это часто бывает, открывался не просто, а ОЧЕНЬ просто! Только после изучения всех советов у меня возникла мысль проверить, а не используется ли tmpfs УЖЕ в моей системе? Оказалось, что используется для /run/lock и /run/shm. Последний - что-то системное, я не вникал, решил - туда лучше не лезть. А вот /run/lock мне подойдёт. Вообще-то этот каталог предназначен для lock-файлов, но вряд ли они способны занять хотя бы 10% от выделенных 5 мегабайт. Я имею в виду - на десктопной машине. Учитывая, что моим файлам никогда не понадобится больше 2 Мб - почему бы и нет?

Если я правильно понял, что мне вывела команда mount, то на tmpfs расположен вообще весь /run. При этом команда ls выводит каталог tmp точно таким же зеленым цветом, как каталоги /run/lock и /run/shm. Возникло подозрение, что /tmp тоже на tmpfs. Однако в команде mount такого каталога не упомянуто. И символической ссылкой он не является. Странно.

Пятисотый написал:

А ларчик, как это часто бывает, открывался не просто, а ОЧЕНЬ просто! Только после изучения всех советов у меня возникла мысль проверить, а не используется ли tmpfs УЖЕ в моей системе? Оказалось, что используется для /run/lock и /run/shm. Последний - что-то системное, я не вникал, решил - туда лучше не лезть. А вот /run/lock мне подойдёт. Вообще-то этот каталог предназначен для lock-файлов, но вряд ли они способны занять хотя бы 10% от выделенных 5 мегабайт. Я имею в виду - на десктопной машине. Учитывая, что моим файлам никогда не понадобится больше 2 Мб - почему бы и нет?

Если я правильно понял, что мне вывела команда mount, то на tmpfs расположен вообще весь /run. При этом команда ls выводит каталог tmp точно таким же зеленым цветом, как каталоги /run/lock и /run/shm. Возникло подозрение, что /tmp тоже на tmpfs. Однако в команде mount такого каталога не упомянуто. И символической ссылкой он не является. Странно.

Чтобы /tmp разместить на tmpfs достаточно добавить в /etc/fstab всего одну строку:

tmpfs /tmp tmpfs defaults 0 0

И сказать #mount -a. После этой нехитрой операции мы получим, что /tmp переедет частично в RAM. То есть пока /tmp не больше половины оперативной памяти, оно держится в ОЗУ, а всё, что больше - уходит на swap-раздел. Если, конечно, не ограничить это дело специальной квотой. Ну а дальше - пользоваться этим RAM-/tmp так как нужно и не стоит лезть в специальные системные каталоги. Для своих приложений надо делать свое.

Перемещение /tmp в RAM благотворно сказывается на производительности компьютера. Но, при этом совершенно ничего не мешает создать свою отдельную точку монтирования и смонтировать tmpfs именно на неё (соответственно, прописав это и в /etc/fstab). И далее размещать свой "зоопарк" именно в своем tmpfs каталоге.

И весь этот сыр-бор, для того, чтобы понять что такое tmpfs...
Вот примерно как выглядит /tmp в tmpfs

Я тут погуглил насчёт /run - это замена /var в новомодных линуксах. Разница в том, что /var может быть где угодно - в той же ФС, на отдельном диске, на ramfs/tmpfs, а /run - всегда на tmpfs. И он предназначен для всех нужд такого рода. То есть идеологически правильно не создавать /tmp на tmpfs, а создать символическую ссылку на какой-нибудь /run/tmp.

А то получится, что /run/shm берёт половину памяти, /tmp на tmpfs теоретически может занять до половины памяти... Вспоминается байка про Ходжу Насреддина, которому неверная жена сказала, что это их кот сожрал четыре килограмма мяса (на самом деле она скормила всё любовнику... интересно, у него не было заворота кишок?) Ходжа Насреддин взвесил кота - весы показали ровно 4 кг - и сказал: "Да, мясо действительно здесь, до последнего грамма, но я никак не могу понять, а где же тогда кот?" Вот и я боюсь оказаться в такой же ситуации: четыре гигабайта я вижу, а где же память?

На всякий случай уточню: я хочу построить систему вообще без своппинга. Памяти много, почти в два раза больше, чем требуется всем приложениям, которые я собираюсь запускать одновременно. Или всё равно лучше своп не отключать?