[xfs][карма] Как починить? И без рестарта? :)

А если теперь смонтировать и размонтировать?

А вообще да, карма.

Смонтировалось. Размонтировалось. Всё без ошибок и глюков. Но по-прежнему: «xfs_check: /dev/mapper/balvg-downloads contains a mounted and writable filesystem»

Карма :)

Если мне память не изменяет, то совсем недавно у вас была проблема с XFS. Может ну ее нафиг, эту FS?

В принципе, как раз сейчас её ещё не поздно сменить на что-то другое. В LVM не распределено ещё почти 300Гб, можно тупо создать новый раздел и перекопировать.

Но на что менять? Для мелочёвки - тут всё понятно. Reiser4 вне конкуренции. Но на больших файлах (а это у меня видеопомойка) я его не тестировал и инструментарий под него пока не развит. И неизвестно, будет ли. XFS привлекает низким уровнем файловой фрагментации и наличием дефрага. ext3 и ext4dev не нравятся по производительности. ReiserFS - высокий уровень фрагментации. JFS - вообще ужас. NTFS - довольно медленно через ntfs-3g :)

ext3 менее всего подвержена кармическому влиянию. В конце концов, что тебе важнее: производительность или сохранность данных?

Ну если вам нужна FS для хранения больших файлов, то какие могут быть проблемы с производительностью у ext3?
Или иерархия директорий на данном разделе сильно замудренная?

>ext3 менее всего подвержена кармическому влиянию.

У меня с ext3 тоже карма :) И если на XFS я за свою историю только файлы единичные терял, то на ext3 лет 5 назад я потерял целиком раздел, а с год назад - кучу системных файлов :)

> В конце концов, что тебе важнее: производительность или сохранность данных?

В данном случае - производительность. Это же файлопомойка. Пропадёт - снова накачаю.

А все важные данные всё равно надо бэкапить.

...

Короче, пошёл писать тест на тестирование FS на работе с большими файлами. Уровень фрагментации после кусочной записи в параллельных потоках и параллельное чтение из середин больших файлов.

АФАЙР рторрент так ругается при наличии файла rtorrent.lock в директории для сохранённых сессий (.rtorrent.session/ или что-то типа этого)

Гы! Есть такой! :D

...

Но в любом случае тест готов (многопоточная фрагментирующая запись 50 файлов общим объёмом 34Гб на раздел в 50Гб, потом чтение каждого из них в 10 потоков из разных мест). Узнаем, кто лучше всего подойдёт для задач p2p :)

Где-то минут по 40 на тестирование одной FS уходит.

rm /home/balancer/downloads/*lock ?

Если ты 'неправильно' завершил сессию рторрента - то он с вероятностью 30% на следующем запуске будет ругаться именно так. А xfs/reiserfs/ext2/ntfs/vfat тут вообще непричем.

>rm /home/balancer/downloads/*lock ?

Угу. Уже разобрались.

...

А тесты для больших файлов я сделал и за ночь прогнал несколько циклов (кроме ext4dev - она у меня отказывается монтироваться почему-то вдруг). Обработаю результаты и выложу. Интересно вышло.

> кроме ext4dev - она у меня отказывается монтироваться почему-то вдруг

Ага, испугалась!

Тесты модифицировал, заставив писать автоматом данные в sqlite-базу, а то задолбался ручками переписывать.

Оставлю как-нибудь на пару ночей и попробую нарисовать красивые статвыборки в чём-нить, типа R.

Пока - грубая оценка.

Время многопоточной записи (34Гб, 50 файлов, 10 потоков, один поток - один файл):
reiser4 - 1351
xfs - 1385
reiserfs - 1669
ext3 - 1989
jfs - 2268

Время многопоточного чтения (каждый файл по отдельности в 30 потоков):
reiser4 - 125,9
jfs - 131,8
ext3 - 132,1
xfs - 141,3
reiserfs - 177,2

Уровень фрагментации, % и среднее число фрагментов на один файл:
jfs - 64 и 2
reiser4 - 72 и 24
ext3 - 72 и 122
xfs - 76 и 182
reiserfs - 90 и 1022

Особенно поразил уровень фрагментации jfs. После её полного фиаско на мелких файлах, так замечательно отработать на крупных... Правда, скорость записи :-/ Видно, потому и медленно.

Как определялись уровни фрагментации?

>Как определялись уровни фрагментации?

=== fragck.pl ===

#!/usr/bin/perl -w. 

#this script search for frag on a fs. 
use strict;.

#number of files. 
my $files = 0;.
#number of fragment. 
my $fragments = 0;.
#number of fragmented files. 
my $fragfiles = 0;.

#search fs for all file. 
open (FILES, "find " . $ARGV[0] . " -xdev -type f -print0 |");.

$/ = "\0";.

while (defined (my $file = <FILES>)) {.
        open (FRAG, "-|", "filefrag", $file);.
        my $res = <FRAG>;.
        if ($res =~ m/.*:\s+(\d+) extents? found/) {.
                my $fragment = $1;.
                $fragments += $fragment;.
                if ($fragment > 1) {.
                        $fragfiles++;.
                }.
                $files++;.
        } else {.
                print ("$res : not understand for $file.\n");.
        }.
        close (FRAG);.
}.
close (FILES);.

print ( $fragfiles / $files * 100 . "% non contiguous files, " . $fragments / $files . " average fragments.\n");

===

Алгоритм не мой, в код не смотрел, чистый копипаст, м.б. и врёт даже :)

...

По сабжу - сегодня ночью прогнал второй раз. Хотя по два теста -
ещё не репрезентативно, но тенденции сохранились те же.

Добавил, кстати, ещё ntfs и vfat:

Заполнение:
ntfs-3g - 2330
vfat - 3171

Чтение:
ntfs-3g - 245
vfat - 423

Фрагментация, %
ntfs-3g - 72%
vfat - 90%

Фрагментация, среднее число кусков в файле:
ntfs-3g - 39
vfat - 2157

Прогоню следующей ночью третий раз, попробую научиться строить
диаграммы в R и как закончу - выложу окончательный вариант :)

...

По общему итогу - reiser4 рулит. Но XFS от него отстаёт не особо сильно,
зато есть утилиты дефрагментации :)

Но при этом reiser4 сам по себе фрагментируется меньше.
И надёжнее, вроде.

В общем, пока в раздумьях :)

Сравни с показаниями xfs_db (только для xfs разумеется)

$ sudo /usr/sbin/xfs_db -r -c frag /dev/mapper/vg1-donkey
actual 1430, ideal 330, fragmentation factor 76.92%

$ sudo /usr/sbin/xfs_fsr -v /dev/mapper/vg1-donkey
/home/donkey start inode=0
ino=153
extents before:6 after:1 DONE ino=153
ino=181
[skip]

$ sudo /usr/sbin/xfs_db -r -c frag /dev/mapper/vg1-donkey
actual 333, ideal 330, fragmentation factor 0.90%

Хе-хе... :D

home bigfat # sudo xfs_db -r -c frag /dev/mapper/balvg-downloads
actual 542579, ideal 43660, fragmentation factor 91.95%

home bigfat # ./fragck.pl /home/balancer/downloads
1.2853470437018% non contiguous files, 14.6383799157687 average fragments.


:D

При этом, что интересно (fragck доработанный с http://forums.gentoo.org/viewtopic-t-429915-postdays-0-postorder-asc-start-25... ):

Total files: 36566
Fragmented files: 470
Fragments: 535267

Total files и fragments хотя бы с точностью до порядка совпадают :)

Так что, видимо, можно достаточно достоверно смотреть на среднее число фрагментов на файл.

Никому нельзя верить

$ sudo ./fragcheck.pl -v /boot
Total files:      17
Fragmented files: 5
Fragments:        24
29.4% non contiguous files, 1.4 average fragments.

$ sudo umount /boot
$ sudo e2fsck -f /dev/sda1
[skip]
Boot: 29/34136 files (20.7% non-contiguous), 28945/136520 blocks

T.e. при такой "точности" измерения фрагментации, как в твоем исходном тесте, лучше ее вообще искл. из результатов, чем оставить как есть.

Процент фрагментации - да.

А вот число фрагментов - вполне адекватно. Для качественной оценки сойдёт.

...

И в любом случае фрагментация параметр вторичный, сама по себе она малоинтересна. Интересна производительность :) А она измеряется в лоб, в секундах на операцию :)

...

Забыл ещё, кстати, ext2 для проформы добавить. Сегодня ночью ещё один цикл прогоню, уже и с ней.

Скрипт теста выложишь? Интересно на моем железе проверить.

http://balancer.ru/files/0809/fs-test-big.tar.bz2

Запускать main.sh, в самом верху в нём - переменная, в которой указан раздел для тестирования. Монтируется в фиксированную точку /mnt/fs-test. Запускать, понятно, от root'а.

А, да. Источник файлового мусора тоже хардкодед в файле fill.sh, переменная SRC.

Спасибо
Разберемся.