Проект заброшен, а 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAle66goACgkQq4wAz/jiZTf51QCcDTpJTaQAQn0+eV8/ H793OU2L
2EgAoKFPZL6WSdemeBOqR+f9VSDuq5gx
=I4IE
-----END PGP SIGNATURE-----