Что представляет из себя директория /proc, /tmp?

Question

[waltaki]

Здравствуйте.

У меня ряд вопросов, насчёт этого.

1) Если /proc не хранит информация не на диске, не в рам - то где вообще? Не понимаю(
2) Например я в bash. Возможно ли как-то получить мой вывод, смотря в папку /proc процесса bash?
3) Если папка /tmp хранится в ОЗУ, могу ли я там хранить свои временные файлы для мгновенного доступа?

4) Как можно реализовать подобное: Есть файл, в который постоянно пишется информация, чтобы он не занимал много места, я ставлю условный лимит в 10000кб, когда файл начинает весить больше, то разница будет стёрта из начала файла. Например файл (огр. в 10байт): f.test
1234567890
Я например в него пишу echo 10 >> f.test,
теперь в файле:
3456789010
Такое возможно реализовать, без крон задач?

Подскажите, просто интересно))

Answer 1

[Saboteur]

1) Если /proc не хранит информация не на диске, не в рам - то где вообще? Не понимаю(

/proc это вообще абстракция. Ядро системы знает какие процессы сейчас запущены и хранит это в памяти. А в /proc визуализирует это, предоставляя некий интерфейс в виде "все есть файл". Просто нужно понимать, что это не ext2/ext3/ext4 эмулируемый в памяти, это именно procfs

2) Например я в bash. Возможно ли как-то получить мой вывод, смотря в папку /proc процесса bash?

да, можете подключиться к вашему stdout, который собственно/proc/<PID>/fd/1
можно посмотреть как вы подключились и куда смотрит ваш /proc/<PID>/fd/1 (скорее всего в какой-нить /dev/pts/0) и оттуда тоже смотреть.

3) Если папка /tmp хранится в ОЗУ, могу ли я там хранить свои временные файлы для мгновенного доступа?

Да. Только нужно помнить, что tmpfs не ограничен, то есть чем больше туда кладешь, тем меньше свободного ОЗУ остается

4) Как можно реализовать подобное: Есть файл, в который постоянно пишется информация, чтобы он не занимал много места, я ставлю условный лимит в 10000кб, когда файл начинает весить больше, то разница будет стёрта из начала файла.

Нужно понимать, что стереть 10 байт из начала файла нельзя, потому что нужно сдвинуть содержимое всего файла. Другими словами - файл целиком придется перезаписать.
Поэтому применяют другой способ - log rotate - когда идет запись в файл, проверяется его размер. Если он превысил значение, файл переименовывается (например в file.log.1) и открывается новый файл file.log
Можно контролировать сколько файлов может быть в списке и не забывать переименовываьт все файлы, чтобы они соответствовали порядку. Но этим нужно заниматься тому, кто пишет в файл.

Comments

[jcmvbkbc]

нужно помнить, что tmpfs не ограничен

из man mount:

Mount options for tmpfs
       size=nbytes
              Override default maximum size of the filesystem.
              The size is given in bytes, and rounded up to entire pages.
              The default is half of the memory.
              The size parameter also accepts a suffix % to limit this tmpfs instance
               to  that  percentage  of  your physical RAM: the default, when neither
               size nor nr_blocks is specified, is size=50%

[jcmvbkbc]

Нужно понимать, что стереть 10 байт из начала файла нельзя, потому что нужно сдвинуть содержимое всего файла.

Можно освободить место в начале, например вызвая fallocate с флагом FALLOC_FL_PUNCH_HOLE, но для этого нужна поддержка со стороны файловой системы.

[Saboteur]

jcmvbkbc, Как я вижу, "The FALLOC_FL_PUNCH_HOLE flag must be ORed with FALLOC_FL_KEEP_SIZE", то есть размер файла не должен изменяться, что противоречит тому, что файл уменьшился на удаленные с его начала несколько байт.

[jcmvbkbc]

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

Saboteur, не, это тупиковый вариант по многим причинам. Я предлагаю логический размер файла не уменьшать, всё время дописывать в конец, но постепенно удалять данные в начале файла, так, чтобы на диске оставался только условный лимит в конце.

[Saboteur]

А как это возможно?
Если мы запускаем fallocate без изменения размера файла, то что выходит? Файл не уменьшается, просто обнуляем данные в его начале.
Затем дописываем в конец новые данные, и вообще получается какая-то фигня.
Мы же не можем дописывать данные в конец и удалять в начале одной командой.?
Fallocate с дыркой вообще делает непонятную для меня вещь.

[jcmvbkbc]

Если мы запускаем fallocate без изменения размера файла, то что выходит? Файл не уменьшается, просто обнуляем данные в его начале.

Saboteur Да.

Мы же не можем дописывать данные в конец и удалять в начале одной командой.?

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

Fallocate с дыркой вообще делает непонятную для меня вещь.

Он виртуально зануляет данные и физически освобождает занятое место. См. sparse file.. Из дырки читаются нули. Если начать туда писать -- выделится физическое пространство. Что-то такое:

$ dd of=sparse bs=1G count=0 seek=1024
0+0 records in
0+0 records out
0 bytes copied, 6.9401e-05 s, 0.0 kB/s

$ stat sparse
  File: sparse
  Size: 1099511627776   Blocks: 0          IO Block: 4096   regular file
Device: fe03h/65027d    Inode: 22684238    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/jcmvbkbc)   Gid: ( 1000/jcmvbkbc)
Access: 2019-08-18 15:42:04.772367087 -0700
Modify: 2019-08-18 15:42:04.776367113 -0700
Change: 2019-08-18 15:42:04.776367113 -0700
 Birth: -

$ echo test >> sparse

$ tail -c 100 sparse | hexdump -Cv
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 74  |...............t|
00000060  65 73 74 0a                                       |est.|
00000064

$ stat sparse
  File: sparse
  Size: 1099511627781   Blocks: 8          IO Block: 4096   regular file
Device: fe03h/65027d    Inode: 22684238    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/jcmvbkbc)   Gid: ( 1000/jcmvbkbc)
Access: 2019-08-18 15:43:25.668878335 -0700
Modify: 2019-08-18 15:43:14.808809836 -0700
Change: 2019-08-18 15:43:14.808809836 -0700
 Birth: -

Т.е. получился файл с размером в терабайт, занимающий на диске 8 блоков по 4К.

[Saboteur]

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

[jcmvbkbc]

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

Saboteur, так не надо делать cat, надо делать tail

[Saboteur]

Понял. Имеет смысл для неструктурированных данных.

Answer 2

[Karpion]

tmpfs обычно хранится в оперативке, но при нехватке памяти может свопиться на диск. Главное её свойство - это отсутствие транзакционных методов работы, необходимых нормальной файловой системе - это даёт скорость, а надёжность там не нужна, ибо при ребуте она чистится.
Хранить там свои файлы - можно и нужно. Но надо помнить: "при ребуте она чистится".

procfs не хранится нигде, а генерится на лету. Поясняю очень приблизительно:

Когда команда ls смотрит обычную файловую систему (обращается в директории, которую обслуживает обычная файловая система), то драйвер файловой системы читает некое хранилище - обычно HDD/SSD. И там лежат имена файлов - их можно найти программой типа diskedit (если Вы заете, что это такое).

Когда команда ls смотрит корень procfs - то драйвер procfs не читает никаких носителей, а запускает внутри себя команду ps (любители корректных формулировок сейчас закидают меня тапками). ps читает список запущенных процессов (который, вообще-то, хранится в памяти - в данных ядра) и передаёт его драйверу procfs. А драйвер procfs на основе этой информации формирует список номеров процессов.

Если команда ls смотрит в поддиректорию procfs - то драйвер procfs берёт информацию из данных ядра конкретно про этот процесс; эта информация тоже лежит в памяти, тоже в данных ядра.

Собственно, разница в том, что драйвер обычной файловой системы читает данные как они лежат - потому делает это строго в монопольном режиме, никто другое не имеет права их трогать. А драйвер procfs работает с данными, которые ядро в любой момент может поменять - и потому не читает их из места хранения, а запрашивает через "кладовщика" - через того же, через кого эти данные запрашивает программа ps и её "родственники".

А есть ещё одна интересная файловая система: devfs для директории /dev ...

Answer 3

[SVM]

1)в озу tmpfs
2)не понял вопроса
3)можешь,если есть права
4)а вот это не знаю/не умею ,будет срать в в своп,и если винт не ssd то будут тормоза
у меня /tmp и кеш браузера смонтирован в оперативку

Comments

[jcmvbkbc]

1)в озу tmpfs

нет. Содержимое /proc генерируется ядром на лету, в момент обращения.

[SVM]

а чё не спится? )))
у нас 5,51 жду 8
тресёт как собаку

[jcmvbkbc]

а чё не спится? )))

у нас 15:57, я в такое время обычно не сплю.

[SVM]

jcmvbkbc,
ты на какой планете живёшь )))

[jcmvbkbc]

ты на какой планете живёшь )))

SOTVM, ты про часовые пояса слышал?

[SVM]

jcmvbkbc,
15,57 думаю только в америке/канаде

[SVM]

jcmvbkbc,
я то из сибири )))

[jcmvbkbc]

15,57 думаю только в америке/канаде

SOTVM, бинго

Answer 4

[Vitsliputsli]

1) в /proc обычно монтируют виртуальную файловую систему дающую доступ к различной информации и ресурсам, предоставляемым ядром.
2) можно, при наличии прав, смотрите устройства tty, или что-то вроде этого.
3) можете при наличии прав.
4) лимиты операционной системы и файловой системы не контролируют содержимое файлов. Но в зависимости от задачи, можно решить, например, с помощью pipe, или ротацией.