ext3 фрагментация

bliznezz - Posted on 11 Апрель 2009

испытываю негативное влияние фрагментации крупных файлов на хранилице бекапов.

операционка rhel4, файловая система соотв. ext3.
для оценки фрагментации использую команду filefrag из e2fs-utils.

она выдает данные в таком виде:

$ find /DUMP1/ /DUMP2/ -type f -name "*.d*mp" -exec filefrag {} \;
/DUMP1/chidori/file1.dump: 73 extents found, perfection would be 27 extents
/DUMP1/chidori/file2.dump: 255 extents found, perfection would be 1 extent
/DUMP1/chidori/file3.dump: 51 extents found, perfection would be 1 extent
/DUMP1/chidori/file_2008.dump: 203 extents found, perfection would be 1 extent.
/DUMP1/chidori/yesterday.dump: 255 extents found, perfection would be 1 extent
/DUMP1/sagara/db/file1.dump: 255454 extents found, perfection would be 317 extents
/DUMP1/sagara/db/file2.dump: 54210 extents found, perfection would be 104 extents
/DUMP1/sagara/db/file3.dump: 16018 extents found, perfection would be 37 extents
/DUMP1/sagara/file_2008.dump: 203 extents found, perfection would be 1 extent.
/DUMP2/altair/flash_recovery_area/s1/full.dmp: 1366 extents found, perfection would be 9 extents
/DUMP2/altair/flash_recovery_area/s2/full.dmp: 462 extents found, perfection would be 4 extents
/DUMP2/georgia/db/1.dmp: 425 extents found, perfection would be 33 extents
/DUMP2/geordia/db/2.dmp: 317 extents found, perfection would be 32 extents
/DUMP2/optimist/db/Dima.dump: 1 extent found

когда объект один-два, еще можно прочитать и оценить трубуется ли дефрагментация, или терпимо.
но когда их много - пришлось нацарапать скриптик на awk

cat calcfrag
/\: 1 extent found/ {next};
/perfection would be/ { printf ("%s %i ext instead of %i.\tfragmentation=%f\n", $1,$2,$8, $2/$8); }.

$ find /DUMP1/ /DUMP2/ -type f -name "*.d*mp" -exec filefrag {} \; | awk -f calcfrag
/DUMP1/chidori/file1.dump: 73 ext instead of 27.        fragmentation=2.703704
/DUMP1/chidori/file2.dump: 255 ext instead of 1.        fragmentation=255.000000
/DUMP1/chidori/file3.dump: 51 ext instead of 1. fragmentation=51.000000
/DUMP1/chidori/file_2008.dump: 203 ext instead of 1.    fragmentation=203.000000
/DUMP1/chidori/yesterday.dump: 255 ext instead of 1.    fragmentation=255.000000
/DUMP1/sagara/db/file1.dump: 255454 ext instead of 317. fragmentation=805.848580
/DUMP1/sagara/db/file2.dump: 54210 ext instead of 104.  fragmentation=521.250000
/DUMP1/sagara/db/file3.dump: 16018 ext instead of 37.   fragmentation=432.918919
/DUMP1/sagara/file_2008.dump: 203 ext instead of 1.     fragmentation=203.000000
/DUMP2/altair/flash_recovery_area/s1/full.dmp: 1366 ext instead of 9.   fragmentation=151.777778
/DUMP2/altair/flash_recovery_area/s2/full.dmp: 462 ext instead of 4.    fragmentation=115.500000
/DUMP2/georgia/db/1.dmp: 425 ext instead of 33. fragmentation=12.878788
/DUMP2/geordia/db/2.dmp: 317 ext instead of 32. fragmentation=9.906250

это происходит из-за того, что при копирование этих файлов идет параллелльно, одновременно до 20 потоков. поэтому фрагментацию до 15 единиц буду считать терпимой.
номрмального метода дефрагментации не знаю, придется копировать файлы на соседний раздел, потом обратно, хорошо что места хватает.

Дефрагментация в линуксе это

Опубликовано Anonymous в Пт, 2009-10-30 07:46.

Дефрагментация в линуксе это от "лукавого".

ответить

Негативное влияние фрагментации

Опубликовано Zenitur в Чт, 2009-07-09 09:04.

Наверное, это - единственный случай, когда может случиться "Негативное влияние фрагментации" - другим пользователям дефрагментация вручную нужна только в Windows.