Мы используем файловые системы ext4 для хранения данных только в одном большом файле.
У нас возникла странная проблема: df сообщает о свободном пространстве (16 МБ), dumpe2fs сообщает о 4096 свободных блоках (из 4 КБ, соответствует тому, что сообщает df), но при попытке добавить данные в наш файл система сообщает, что на устройстве не осталось места.
[root@localhost raw_2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdd1 11G 11G 16M 100% /opt/HIDDEN/storage/raw_2
[root@localhost raw_2]# df -i .
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 11264 12 11252 1% /opt/HIDDEN/storage/raw_2
[root@localhost raw_2]# echo test > testfile
-bash: echo: write error: No space left on device
[root@localhost storage]# umount /dev/sdd1
[root@localhost storage]# dumpe2fs -h /dev/sdd1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: /opt/HIDDEN/storage/raw_2
Filesystem UUID: 9d6ca417-0854-461d-993d-e23c2a2229d4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 11264
Block count: 2883580
Reserved block count: 0
Free blocks: 4096
Free inodes: 11251
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 703
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 128
Inode blocks per group: 8
Flex block group size: 2048
Filesystem created: Tue Nov 15 11:32:52 2016
Last mount time: Tue Dec 6 14:14:57 2016
Last write time: Tue Dec 6 15:16:54 2016
Mount count: 8
Maximum mount count: 32
Last checked: Tue Nov 15 11:32:52 2016
Check interval: 15552000 (6 months)
Next check after: Sun May 14 12:32:52 2017
Lifetime writes: 3572 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: dc8da308-ef45-4bea-b156-5690eb399646
Journal backup: inode blocks
Journal features: (none)
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0004a45b
Journal start: 0
Это не связано с зарезервированными блоками для root и, очевидно, не связано со свободными индексными дескрипторами.
Я прочитал много обсуждений, но не нашел ничего, что могло бы относиться к нашему случаю.
Эта проблема возникает на виртуальной машине с виртуальными дисками 11 ГБ. Мы также наблюдали такое же поведение при использовании файлов размером 10 ГБ, смонтированных как loopback FS. Мы используем RedHat 6 (linux 2.6.32).
Наше программное обеспечение работает от имени пользователя root. Я также попробовал простой cat / dev / zero> testfile, он остановился на том же пределе, оставив 16 МБ свободного места.
Любая помощь будет оценена.
РЕДАКТИРОВАТЬ: использование statfs в двух разных системах показывает странное поведение.
В моей исходной системе statfs не сообщает о разнице f_bfree == f_bavail:
statfs("/opt/HIDDEN/storage/raw_1/", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=2882680, f_bfree=2665715, f_bavail=2665715, f_files=11264, f_ffree=11251, f_fsid={-2032429898, 1911081970}, f_namelen=255, f_frsize=4096}) = 0
В тестовой коробке Debian (linux 4.8.0):
statfs("/home/", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=55137925, f_bfree=26426280, f_bavail=26422184, f_files=10114944, f_ffree=9685471, f_fsid={1010187930, 3946494061}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
Эта fs не имеет зарезервированных блоков, но есть разница в 4096 блоков между f_bavail (свободные блоки, доступные непривилегированному пользователю) и f_bfree (свободные блоки в fs). Кто-нибудь знает, что это за 4096 зарезервированных блоков?
Спасибо.
/dev/sdd1 11G 11G 16M 100% /opt/HIDDEN/storage/raw_2
100% заполнено означает заполнено на 100%. Ничего больше не может быть записано в этот раздел, пока вы не станете менее 100%. Рискну предположить, что 16 МБ свободного места - это фрагментированное, а не непрерывное пространство.
Почти все файловые системы, включая ext4, резервируют место для своих метаданных, журнала и обработки фрагментов. Вы, вероятно, видите эффект от этого зарезервированного / неиспользуемого пространства.
В любом случае, запуск файловой системы с истинным 100% использованием - очень плохая идея. Всегда зарезервируйте свободное место для работоспособной файловой системы.
ОБНОВИТЬ: это цитата из список рассылки ядра объясняя, почему именно 4096 блоков зарезервированы для использования файловой системой:
И здесь на сцену выходит зарезервированное пространство. При монтировании файловой системы мы отрезаем небольшую часть пространства файловой системы (2% или 4096 кластеров, в зависимости от того, что меньше), которое затем можно использовать в случаях, упомянутых выше, для предотвращения дорогостоящего обнуления или неожиданного ENOSPC.
Количество зарезервированных кластеров может быть установлено через sysfs, однако оно никогда не может быть больше, чем количество свободных кластеров в файловой системе.