Tomsk Sysadmins Forum
Unix => Администрирование => Topic started by: koldoon on March 29, 2009, 16:25:58
-
Народ грамотный, кто имел дело с файловыми системами на reiserfs и ext3. Проблема в следующем: у меня файловый сервер на линукс (Suse 11), на нем два винта по 500 Гб (якобы. реально - на 459, ну да это не важно...). Первый раз столкнулся с проблемой где-то год назад. Тогда я создавал разделы на дисках в reiserfs и потом у меня начало "пропадать" свободное место. Что значит "пропадать" - фактически занимаемый размер информации на диске меньше, чем если от всего объема вычесть свободное место. Кто-то мне сказал тогда, что рейзер сам по себе может быть не стабилен и хорошо бы от него избавиться. И вот, теперь у меня два раздела на ext3. Проблема та же. Причем сначала все было нормально, а по мере заполнения диска и соответственно его эксплуатации (запись/удаление больших и маленьких файлов) место опять начало "пропадать". Интересен тот факт, что если, например, удалить файл с раздела размером в 3-4 Гб, то обратно его записать уже не представляется возможным, т.е. фактически освобожденное место будет в разы меньше!
Мое личное мнение -- это то, что виной всему жуткая фрагментация раздела, но линукс не предоставляет никаких средств для борьбы с этим, и вообще все везде говорят, что это не требуется. Хорошо, тогда что это может быть и как с этим бороться?
Вот лог нескольких команд:
#:/mnt/disk2 # du --max-depth=1 -x -h
4.0K ./lost+found
429G ./archive
429G .
#:/mnt/disk2 # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 20G 19G 12M 100% /
udev 1010M 96K 1010M 1% /dev
/dev/sda3 208G 188M 197G 1% /mnt/sys
/dev/sdb1 459G 389G 47G 90% /mnt/disk1 <--- 459 - 389 = 70 != 47
/dev/sdc1 459G 429G 6.5G 99% /mnt/disk2 <--- 459 - 429 = 30 != 6.5
-
fsck прогоняли по разделам?
/dev/sda2 20G 19G 12M 100% /
Чего ж вы корень то так засрали, что там всего 12 мегабайт свободно?
-
нормальная FS резервирует чуток процентов от диска на непредвиденную кончину места.
tunefs че говорит? (tune3fs для ext3?)
-
нативный дефрагментатор имеет xfs
# apt-get install xfsdump
# man xfs_db
# man xfs_fsr
# xfs_db -r /dev/mapper/LVMoverRAID-eGW
xfs_db> frag
actual 1062, ideal 14, fragmentation factor 98.68%
xfs_db> quit
# xfs_fsr -v /dev/mapper/LVMoverRAID-eGW
/vms/eGW start inode=0
ino=139
extents before:1014 after:1 DONE ino=139
ino=131
insufficient freespace for: ino=131: size=2040109056: ignoring
ino=134
extents before:12 after:1 DONE ino=134
ino=133
extents before:6 after:1 DONE ino=133
ino=8388739
insufficient freespace for: ino=8388739: size=2147221504: ignoring
ino=8388748
No improvement will be made (skipping): ino=8388748
ino=135
extents before:2 after:1 DONE ino=135
#
еще раз
# xfs_fsr -v /dev/mapper/LVMoverRAID-eGW
/vms/eGW start inode=0
ino=131
insufficient freespace for: ino=131: size=2040109056: ignoring
ino=8388739
insufficient freespace for: ino=8388739: size=2147221504: ignoring
ino=8388748
No improvement will be made (skipping): ino=8388748
# df -h /dev/mapper/LVMoverRAID-eGW
/dev/mapper/LVMoverRAID-eGW
5.0G 4.6G 473M 91% /vms/eGW
#
слишком мало свободного места. как и у топикстартера. надо сперва выгрузить чуток хламу.
тулза эта дефрагментирует методом копирования-и-переименования.
но если начинать с пустого раздела и ежедневно натравливать xfs_fsr - то разделы будут практически всегда нефрагментированные.
а можно посмотреть фрагметы конкретного файла
# xfs_bmap -v /vms/eGW/eGroupWare-f001.vmdk
/vms/eGW/eGroupWare-f001.vmdk:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..664831]: 2621544..3286375 2 (104..664935) 664832
1: [664832..1330687]: 3932224..4598079 3 (64..665919) 665856
2: [1330688..2163327]: 5263424..6096063 4 (20544..853183) 832640
3: [2163328..2819583]: 6553664..7209919 5 (64..656319) 656256
4: [2819584..3482623]: 7864384..8527423 6 (64..663103) 663040
5: [3482624..4193791]: 9175104..9886271 7 (64..711231) 711168
#
xfs_fsr запущенная без параметров пройдётся по всем смонтированным xfs разделам. по умолчанию тарабанит 2 часа, затем останавливается и продолжает с места остановки при следующем старте.
или наоброт можно дефрагментировать отдельный файл.
на отдельные файлы можно повесить флаг no_defrag. типа связанные с lilo.
-
Для ext2/3 и reiserfs когда то писал скрипт на bash, определяющий количество фрагментов у файла (штатные утилиты для работы с этими fs, возможно есть для всех) и если их количество по сравнению размером файла больше определенного числа (точнее средний размер фрагмента меньше определенной заранее константы, например 50мб - линейная скорость чтения с диска) запускалось перемещение файла на другой раздел и обратно. Сейчас скрипт найти не могу но он был несколько строк и его хватало более чем.
Единственный случай фрагментирования, с которым не справляются дефрагментаторы такого типа - фрагментация свободного пространства. Решение - освободить побольше места. Еще вариант - backup + format + restore.
-
fsck прогоняли по разделам?
/dev/sda2 20G 19G 12M 100% /
Чего ж вы корень то так засрали, что там всего 12 мегабайт свободно?
fschk -- это первое, что обычно делается
-
#: tune2fs -l /dev/sdb1
tune2fs 1.40.2 (12-Jul-2007)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 09b96e32-623d-4b9c-8789-09ca27edaee4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal 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: 61063168
Block count: 122096000
Reserved block count: 6104800
Free blocks: 18398268
Free inodes: 60617600
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 994
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Sun Apr 27 01:31:55 2008
Last mount time: Sun Mar 29 18:11:20 2009
Last write time: Sun Mar 29 18:11:20 2009
Mount count: 1
Maximum mount count: 25
Last checked: Sun Mar 29 13:29:22 2009
Check interval: 15552000 (6 months)
Next check after: Fri Sep 25 13:29:22 2009
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: af1428f1-ffa0-4e4d-aaa9-ecffb5d68324
Journal backup: inode blocks
-
Для ext2/3 и reiserfs когда то писал скрипт на bash, определяющий количество фрагментов у файла (штатные утилиты для работы с этими fs, возможно есть для всех) и если их количество по сравнению размером файла больше определенного числа (точнее средний размер фрагмента меньше определенной заранее константы, например 50мб - линейная скорость чтения с диска) запускалось перемещение файла на другой раздел и обратно. Сейчас скрипт найти не могу но он был несколько строк и его хватало более чем.
Единственный случай фрагментирования, с которым не справляются дефрагментаторы такого типа - фрагментация свободного пространства. Решение - освободить побольше места. Еще вариант - backup + format + restore.
как посмотреть количество фрагентов для файлов на ext3?
-
Я тут попробовал "передернуть" часть информации на диске путем переноса на другой диск и обратно... посмотрим, что из этого выйдет...
-
как посмотреть количество фрагентов для файлов на ext3?
Для ext3, как ни странно, filefrag из пакета sys-fs/e2fsprogs (gentoo) он точно есть практически во всех дистрибутивах, может называется по разному.
P.S. полное перекопирование всех файлов диска.. скрипт (ссылка из вики кстати) http://ck.kolivas.org/apps/defrag/ (http://ck.kolivas.org/apps/defrag/)
-
Reserved block count: 6104800
умножить на
Block size: 4096
=
25005260800
или ~23G которые недосчитались в 'df -h'
можно уменьшнить количество зарезервированного места, сделать его равным 0, освободится 23G, man tunefs или погуглить.
место оно всегда кончается
и в общем случае лучше купить доп. винт или заменить на более емкий или хотя бы запланировать это на ближайшее будущее.
и планировать заранее, например при перешагивании 80% занято.
-
Если сервер не проявляет тенденции к склеиванию ласт, проще купить диск, перенести туда usr и var например, на старый - кинуть линки.
-
Поставил reserved_blocks_count = 100 (на всякий случай чуток оставил). посмотрим, что будет...
Еще нашел скрипт, который передергивает файлы рекурсивно в заданном каталоге.... тоже потестим. Если кому интересно, потом отпишусь, как все прошло. А так, всем спасибо за советы
Кстати, картина теперь такая:
#: df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 20G 19G 442M 98% /
udev 1010M 104K 1010M 1% /dev
/dev/sda3 208G 188M 197G 1% /mnt/sys
/dev/sdb1 459G 398G 61G 87% /mnt/disk1
/dev/sdc1 459G 431G 29G 94% /mnt/disk2