Дано: сервер с полусофтварным рейд-массивом, настроенным как RAID5, FreeBSD 7.0, UFS, samba. Рейд монтируется целиком и расшаривается самбой в виндовый домен. Объем рейда - 1,8 Тб, занято - 1,2 Тб.
Задача: снапшоты с UFS через некоторые промежутки времени.Снапшоты делались согласно ману http://people.freebsd.org/~rse/snapshot/
Первый снапшот снимался ~12 минут. Второй - ~18. При этом все данные были доступны по сети. Третий снапшот ~25 минут. Примерно за 5 минут до окончания снятия отвалилась samba. Поднялась сама по окончании. В ее логах - никакого криминала. Четвертый - то же самое.
Далее, с периодичностью примерно раз в час (снапшотов больше НЕ делалось) вылет самбы. В итоге полное зависание системы примерно через 10 часов после последнего снапшота.В логе messаges следующие строки:
May 12 22:21:40 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:21:40 fileserver kernel: WARNING: /data was not properly dismounted
May 12 22:26:03 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:26:03 fileserver kernel: WARNING: /data was not properly dismounted
May 12 22:27:21 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:27:21 fileserver kernel: WARNING: /data was not properly dismounted
May 12 22:27:31 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:27:31 fileserver kernel: WARNING: /data was not properly dismounted
May 12 22:39:26 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:42:15 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 22:42:15 fileserver kernel: WARNING: /data was not properly dismounted
May 12 23:30:26 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 12 23:30:26 fileserver kernel: WARNING: /data was not properly dismounted
May 13 01:07:20 fileserver kernel: WARNING: Expected rawoffset 0, found 63
May 13 01:07:20 fileserver kernel: WARNING: /data was not properly dismounted/data - точка монтирования рейда.
Время с 22:21:40 до 22:42:15 соответствует времени снятия четвертого снапшота.
Машина в аварийный ребут не ходила.
После снятия третьего снапшота df -h отвечать перестал, работал только с указанием точки монтирования.Сами снятые снапшоты вполне жизнеспособны. Монтируются, отмонтируются, дают вытащить данные.
Рейд глюками ранее не страдал.
После рестарта машины все нормализовалось. Эксперименты со снапшотами больше не ставились.Очень хотелось бы услышать мнение на этот счет. Никакой информации по конфликтам снапшотов с самбой ранее не встречал (если дело в этом, конечно)
>Первый снапшот снимался ~12 минут. Второй - ~18. При этом все данные
>были доступны по сети. Третий снапшот ~25 минут. Примерно за 5
>минут до окончания снятия отвалилась samba. Поднялась сама по окончании. В
>ее логах - никакого криминала. Четвертый - то же самое.То есть каждый час генерится снапшот и предыдущий не удаляется? Если да, то, имхо, UFS таких издевательст долго не выдержит. Была бы это ZFS, тогда другое дело.
>>Первый снапшот снимался ~12 минут. Второй - ~18. При этом все данные
>>были доступны по сети. Третий снапшот ~25 минут. Примерно за 5
>>минут до окончания снятия отвалилась samba. Поднялась сама по окончании. В
>>ее логах - никакого криминала. Четвертый - то же самое.
>
>То есть каждый час генерится снапшот и предыдущий не удаляется? Если да,
>то, имхо, UFS таких издевательст долго не выдержит. Была бы это
>ZFS, тогда другое дело.Т.е. UFS не может работать с ветками снапшотов? По сюжету же, один снапшот держит до 20 модификаций.
>Т.е. UFS не может работать с ветками снапшотов? По сюжету же, один
>снапшот держит до 20 модификаций.Имеется в виду одна фаловая система держит до 20 снапшотов. Раз нужно так много снапшотов, значит туда кто-то что-то пишет я так понял, и причем много. Один снапшот в таком случае уже будет давать наргузку на дисковую подсистему, два еще больше и так далее. И потом делать снапшот на 1.2 Тб - О_о это нада железные нервы иметь :)
А мане эсть такие строчки (правда это уже про монтирование снапшотов):
Note that under some circumstances, the process accessing
the frozen filesystem may deadlock.