[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mhddfs стал отваливаться.



В общем за время пользования почти в 1 год с ext4 разделами (8шт) по 445 гб каждый
с суммарным объемом 3500 гб (HDD 4TB)
ловил зависания Ubuntu Server и Debian с периодичностью от 2 суток до 9-10 дней
обновления ставились своевременно
Подобная конфигурация с 6 разделами суммарным объемом ~3 тб на другом сервере тоже приводили к фризу
к сожалению обе железки были без мониторов и что там происходило на экране я сказать не могу

3 недели назад на домашнем сервере избавился от mhddfs перевел все 8 блочных устройств на LVM тома, зависания не было ни разу
Вторая обслуживаемая мною конфигурация тоже избавлена от mhddfs

Что еще хуже, если поставить копировать пару терабайт по сети (samba) на mhddfs раздел, периодически копирование останавливается с ошибкой, нажатие кнопок "повтор" продолжает копирование данных, но последующее сравнивание файлов по содержимому показывает что на файлах которых происходил сбой копирования оказывается внутри все заполнено пустотой, на крупных файлах как правило такое редко заметно, а вот на сотнях/тысячах как правило процент поврежденных файлов стремительно увеличивался, благо данные в обоих конфигурациях дублируются и бэкапы спасли

Мое личное заключение mhddfs зло повреждающее файлы, т.к. после перевода на LVM ни единого файла во время копирования туда-сюда не повредилось
Ранее что бы не терять файлы и не проверять их целостность на серверах во время копирования, приходилось их сжимать в архив, считать для них md5 и сверять периодически.

Для небольших объемов и малого кол-ва устройств/каталого в массиве mhddfs возможно подходит, но при дальнейшем масштабировании от него лучше отказаться.

____
Munko O. Bazarzhapov
JabberID: vech@aginskoe.ru
mail: vech2k@gmail.com

15 апреля 2016 г., 15:09 пользователь Munko O. Bazarzhapov <vech2k@gmail.com> написал:
в настройках качалки есть опция что бы при скачивании сначала создавал для закачки все файлы соответственно размерам и только после этого начинал закачку?
торрент без этой опции создает файл размером несколько сегментов (допустим 100мб из 1гб), mhddfs выделяет место на первом свободном устройстве 100мб, и на этом первом устройстве вообще свободно всего 500мб, по пере скачивания файл увеличивается в размерах и когда он доходит до лимитов первого устройства что происходит?
я не замечал что бы у меня mhddfs что то переносил автоматом при увеличении файла, да и разделять файл на куски он не умеет, у самого в там фейкрайде 8 устройств по 700-800 гб

____
Munko O. Bazarzhapov
JabberID: vech@aginskoe.ru
mail: vech2k@gmail.com

15 апреля 2016 г., 0:03 пользователь Pavel Shurubura <pavelshurubura@gmail.com> написал:

Спасибо за ответ. 
lvm - пробовал - для дома это overhead.
raid 0 - там по моему размер дисков должен быть одинаков (или всё выравнивается по минимальному), а у меня: 500Gb, 2 Tb, 1 Tb.
А unionfs - это не то?  Стоит смотреть?
И ещё вопрос: на x64 mhddfs будет стабильнее?


14 апреля 2016 г., 17:53 пользователь Yuriy M. Kaminskiy <yumkam+debian@gmail.com> написал:

Pavel Shurubura <pavelshurubura@gmail.com> writes:

> Здравствуйте, community!
>
> После установки дополнительного нового винта в систему debian stable
> (jessie) начались траблы с mhddfs. Конфигурация приблизительно такая:
>
> /dev/sda1 смонтирован /mnt/disk1 (опции монтирования: defaults,
> noatime)
> /dev/sdb1 смонтирован /mnt/disk2 (опции монтирования: defaults,
> noatime)
> /dev/sdc1 смонтирован /mnt/disk3 (опции монтирования: defaults,
> noatime)
>
> в fstab прописано монтирование
> mhddfs#/mnt/disk1,/mnt/disk2,/mnt/disk3 /home/user/torrent fuse
> defaults,noatime,mlimit=100% 0 0
>
> т.е. все 3 диска объединены в одно пространство.
>
> После добавления 3-го диска, начались проблемы:
> rtorrent скачивает только часть файла (приблизительно 2 Гб) всё
> остальное пропадает...
> т.е. показывает, что закачка завершена на 100%, но при rehash остаётся
> только несколько % и соответственно только часть файла.
>
> При rehash большой коллекции файлов вообще rtorrent отваливается с
> сообщением: конечная точка не подсоединена.
> соответственно при попытке:
> ls -al /home/user/torrent
> тоже получаем ошибку: конечная точка не подсоединена.
> По команде mount, точки монтирования /home/user/torrent нет.
> В логах есть падение mhddfs (segfault).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728310
(без решения, без backtraces [что, впрочем, затруднено отсутствием -dbg
пакета и неподдержкой nostrip в debian/rules], и т.д.)

Беглый взгляд на исходники показывает возможный racing, см. патч
(Disclaimer: патч *не проверен*, я не пользуюсь mhddfs, и знаю примерно
ничего про fuse).

> Помогите разобраться, кто сталкивался, либо подскажите чем его
> заменить (более стабильное что-то, но по функциональности такое-же).

lvm, raid0,...? Оно, конечно, менее удобно в рулении, но.

P.S. из логов сборки (к падениям, впрочем, отношения не имеет):
src/parse_options.c: In function 'parse_options':
src/parse_options.c:253:39: warning: integer overflow in _expression_ [-Woverflow]
  mhdd.move_limit = DEFAULT_MLIMIT;
                                       ^
src/parse_options.c:295:42: warning: integer overflow in _expression_ [-Woverflow]
     mhdd.move_limit = DEFAULT_MLIMIT;
                                          ^
(Иными словами, на 32-битных платформах оно по умолчанию немножко поломатое).




--
With kindest regards, pvs.



Reply to: