/var/log/lastlog записывается при входе в систему. Размер этого файла основан на самом большом UID в системе. Чем больше максимальный UID, тем больше размер этого файла. К счастью, это разреженный файл, поэтому размер на диске намного меньше размера ls отчеты (ls -s сообщает размер на диске).
В нашей системе мы проверяем подлинность на сервере Active Directory, и пользовательские идентификаторы UID оказываются очень, очень большими. Например, 900000000 UID для первого пользователя AD, 9000000001 для второго и т. Д.
Это странно, но все должно быть в порядке. Это приводит к /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
Я пробовал поискать в Google «максимальный размер файла 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 это не годится.
Ответ можно найти в исходниках 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-битной тестовой системе FC6, большие размеры возможны с 32-битным ядром.
Похоже, что изменение размера страницы может быть связано чтобы позволить Поддержка файловой системы 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