Проект заброшен, а fuse ушел далеко вперед. Там видимо надо налаживать совместимость с более современным API fuse. Кроме того многие файловые операции fuse не поддерживает. С самбой over fuse могут быть проблемы. On 20:57 Mon 22 Aug , Munko O. Bazarzhapov wrote: > В общем за время пользования почти в 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. -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature