RHEL5: невозможно создать разреженный файл размером более 256 ГБ в tmpfs
/var/log/lastlog записывается при входе в систему. Размер этого файла зависит от наибольшего UID в системе. Чем больше максимальный UID, тем больше этот файл. К счастью, это редкий файл, поэтому размер на диске намного меньше, чем размер ls отчеты (ls -s сообщает размер на диске).
В нашей системе мы проводим аутентификацию на сервере Active Directory, и пользователям назначаются идентификаторы UID, которые в итоге становятся очень большими. Например, UID 900 000 000 для первого пользователя AD, 900 000 001 для второго и т. Д.
Это странно, но должно быть хорошо. Это приводит к /var/log/lastlog будучи huuuuuge, хотя - как только пользователь AD входит в систему lastlog показывает как 280 ГБ. Его реальный размер все еще мал, к счастью.
Это прекрасно работает, когда /var/log/lastlog хранится на жестком диске в файловой системе ext3. Это ломается, однако, если lastlog хранится в файловой системе tmpfs. Затем выясняется, что максимальный размер файла для любого файла в tmpfs составляет 256 ГБ, поэтому sessreg из-за ошибок программы, пытающихся записать lastlog,
Откуда исходит ограничение в 256 ГБ и как его увеличить?
В качестве простого теста для создания больших разреженных файлов я делал:
dd if=/dev/zero of=sparse-file bs=1 count=1 seek=300GB
Я пробовал Googling для "максимальный размер файла tmpfs", "ограничение файловой системы 256 ГБ", "максимальный размер файла linux" и тому подобное. Я не смог найти много. Единственное упоминание о 256 ГБ, которое я могу найти, состоит в том, что файловые системы ext3 с блоками 2 КБ ограничены файлами 256 ГБ. Но наши жесткие диски отформатированы с блоками 4K, так что, похоже, это не так - не говоря уже о том, что это происходит в tmpfs, установленном в верхней части жесткого диска, поэтому раздел ext3 не должен быть фактором.
Все это происходит в 64-битной системе Red Hat Enterprise Linux 5.4. Интересно, что на моей персональной машине для разработки, которая представляет собой 32-разрядную версию Fedora Core 6, я могу без проблем создавать более 300 ГБ файлов в файловых системах tmpfs. На системах RHEL5.4 это не пойдет.
2 ответа
Ответ находится в источнике Linux, в частности, /usr/src/linux/mm/shmem.cНачиная примерно со строки 70 в моей системе (Gentoo 2.6.31-ish):
/*
* The maximum size of a shmem/tmpfs file is limited by the maximum size of
* its triple-indirect swap vector - see illustration at shmem_swp_entry().
*
* With 4kB page size, maximum file size is just over 2TB on a 32-bit kernel,
* but one eighth of that on a 64-bit kernel. With 8kB page size, maximum
* file size is just over 4TB on a 64-bit kernel, but 16TB on a 32-bit kernel,
* MAX_LFS_FILESIZE being then more restrictive than swap vector layout.
Одна восьмая из 2 ТБ - ровно 256 ГБ. Большие размеры возможны с 32-битным ядром, как вы обнаружили с вашей 32-битной тестовой системой FC6.
Похоже, что изменение размера страницы может быть связано с включением поддержки файловой системы HugeTLB в ядре. Тем не менее, я не знаю достаточно о внутренностях ядра, чтобы сказать, как и почему, или какие шаги нужно предпринять, чтобы воспользоваться этим, или какие другие последствия это может иметь. Чтобы включить его, запустите make menuconfig, перейдите к Файловые системы, а затем Псевдо файловые системы. Рассматриваемая опция - поддержка файловой системы HugeTLB. В онлайн-справке говорится:
CONFIG_HUGETLBFS:
hugetlbfs is a filesystem backing for HugeTLB pages, based on
ramfs. For architectures that support it, say Y here and read
<file:Documentation/vm/hugetlbpage.txt> for details.
If unsure, say N.
Возможно, стоит запустить это и в StackOverflow. Надеюсь, это поможет.
Одно предложение... не могли бы вы сделать образ ext3 в tmpfs и смонтировать его, и поместить туда lastlog? Что-то вроде:
cd /tmp
dd if=/dev/zero of=lastlog.img bs=1024k count=10
losetup /dev/loop1 lastlog.img
mkfs.ext3 /dev/loop1
mount /dev/loop1 /var/lastlog