ext3 на LVM, потерялось 200Gb
Модератор: SLEDopit
ext3 на LVM, потерялось 200Gb
Доброго времени суток всем!
Ситуация следующая: есть сервер с LVM на двух терабайтных носителях ( LVM нужен для того, что-бы в дальнейшем наращивать ёмкость без изменений в структуре папок ), на нём ext3. После заполнения более 80% процентов, заметил странную вещь: по версии "df -H" на томе занято 1.8Tb, а по версии "du -h --apparent-size папка_монтирования" занято 1.6Tb...
Вопрос: куды могло убежать 200Gb и можно ли их вернуть?
Ситуация следующая: есть сервер с LVM на двух терабайтных носителях ( LVM нужен для того, что-бы в дальнейшем наращивать ёмкость без изменений в структуре папок ), на нём ext3. После заполнения более 80% процентов, заметил странную вещь: по версии "df -H" на томе занято 1.8Tb, а по версии "du -h --apparent-size папка_монтирования" занято 1.6Tb...
Вопрос: куды могло убежать 200Gb и можно ли их вернуть?
Re: ext3 на LVM, потерялось 200Gb
А зачем вы добавили --apparent-size? В мане же написано, что
PS Ну, и кроме неиспользованных хвостов в последних блоках, которые вы отключили той опцией, есть ещё сама таблица файловой системы, со всеми inode, журанлом и другой информацией. Так что, нет, не получится "вернуть", потому что они не потеряны, а вполне себе используются.--apparent-size
print apparent sizes, rather than disk usage
Последний раз редактировалось NickLion 21.03.2018 10:56, всего редактировалось 1 раз.
Re: ext3 на LVM, потерялось 200Gb
Ещё надо посмотреть на процент зарезервированного пространства. По умолчанию ext3 должен резервировать 5%. Можно посмотреть через tune2fs -l, параметр Reserved block count. Этой же утилитой можно изменить размер резерва.
Re: ext3 на LVM, потерялось 200Gb
1. df вроде не учитывает резерв, как и du. Данная разница не в этом. Но согласен, что может быть ещё место, а получить ошибку, что место закончилось, поэтому проверить/уменшить если надо стоит.
2. Сейчас, вроде, 5% уже не ставят, обычно около 2.5%. Или это только в openSUSE так?
Re: ext3 на LVM, потерялось 200Gb
Без --apparent-size те-же 1.6 Tb показывает.
Imho, 10% на служебную инфу, это мягко говоря слишком дофига!NickLion писал(а): ↑21.03.2018 10:50PS Ну, и кроме неиспользованных хвостов в последних блоках, которые вы отключили той опцией, есть ещё сама таблица файловой системы, со всеми inode, журанлом и другой информацией. Так что, нет, не получится "вернуть", потому что они не потеряны, а вполне себе используются.
Кстати, а вот журналы никак нельзя поубавить?
Re: ext3 на LVM, потерялось 200Gb
Ещё как учитывает и ещё как ставят. Учитывает в том смысле, что "Размер" будет больше чем "Использовано"+"Доступно" на искомые 5%.NickLion писал(а): ↑21.03.2018 11:021. df вроде не учитывает резерв, как и du. Данная разница не в этом. Но согласен, что может быть ещё место, а получить ошибку, что место закончилось, поэтому проверить/уменшить если надо стоит.
2. Сейчас, вроде, 5% уже не ставят, обычно около 2.5%. Или это только в openSUSE так?
Re: ext3 на LVM, потерялось 200Gb
Mrakobes, ты бы показал вывод df -T и tune2fs -l, иначе гадать можно долго.
Может ты вообще забыл, что харды на 1ТБ на самом деле 0.9ГБ имеют размер.
В общем не надо пересказывать своими словами. Показывай конкретный вывод конкретных команд.
Может ты вообще забыл, что харды на 1ТБ на самом деле 0.9ГБ имеют размер.
В общем не надо пересказывать своими словами. Показывай конкретный вывод конкретных команд.
Последний раз редактировалось Vascom 21.03.2018 11:33, всего редактировалось 1 раз.
Re: ext3 на LVM, потерялось 200Gb
Ну, в openSUSE по умолчанию 2.5%, видимо, обоснованно, решили, что 5% сейчас избыточно.
А разницы в df от пользователя и от рута я не вижу, хотя руту доступны те проценты.
Re: ext3 на LVM, потерялось 200Gb
Код: Выделить всё
root@Server:/home/first# df -T
Файловая система Тип 1K-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/mapper/archive-archive_DSN ext3 1921682296 1671250328 230907484 88% /var/archive
Код: Выделить всё
root@Server:/home/first# tune2fs -l /dev/mapper/archive-archive_DSN
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name: <none>
Last mounted on: /var/archive
Filesystem UUID: d57493b3-aaa5-40ce-922f-a95f0bdd83e7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244056064
Block count: 488112128
Reserved block count: 4881121
Free blocks: 64396005
Free inodes: 243772332
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 907
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Tue Jan 29 16:03:39 2013
Last mount time: Tue Feb 20 17:30:36 2018
Last write time: Wed Mar 21 12:16:08 2018
Mount count: 1
Maximum mount count: 31
Last checked: Tue Feb 20 16:52:15 2018
Check interval: 15552000 (6 months)
Next check after: Sun Aug 19 16:52:15 2018
Lifetime writes: 626 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 33ac8743-a210-4f2d-b72b-def8735209ce
Journal backup: inode blocks
Re: ext3 на LVM, потерялось 200Gb
ЗЫ. Reserved block count только-что уменьшил. Было 243772332
Re: ext3 на LVM, потерялось 200Gb
ОК, проблема решена?
Можешь до нуля уменьшить, тебе же не важно.
Можешь до нуля уменьшить, тебе же не важно.
Re: ext3 на LVM, потерялось 200Gb
Дошло. Сам себе мозг травмировал.
df -h даёт вполне себе соответствующий du -h отчет...
Вопрос исчерпан.
df -h даёт вполне себе соответствующий du -h отчет...
Вопрос исчерпан.