А что сейчас актуальное можно опробовать что бы тупо пространство из смонтированных папок склеивать, пару месяцев пробежался, почти все заброшено, unionfs или aufs были какие то проблемы с очередностью записи наследие от squashfs вообще не устраивается у меня логически в голове если точек монтированя делать больше 3 (у меня например тестовый стенд из 8 точек с разными объемами)
____ Munko O. Bazarzhapov JabberID: v...@aginskoe.ru mail: vec...@gmail.com 22 августа 2016 г., 21:03 пользователь Dmitry E. Oboukhov <un...@debian.org> написал: > > Проект заброшен, а 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: v...@aginskoe.ru > > mail: vec...@gmail.com > > > 15 апреля 2016 г., 15:09 пользователь Munko O. Bazarzhapov < > vec...@gmail.com> > > написал: > > > в настройках качалки есть опция что бы при скачивании сначала создавал > для > > закачки все файлы соответственно размерам и только после этого начинал > > закачку? > > торрент без этой опции создает файл размером несколько сегментов > (допустим > > 100мб из 1гб), mhddfs выделяет место на первом свободном устройстве > 100мб, > > и на этом первом устройстве вообще свободно всего 500мб, по пере > скачивания > > файл увеличивается в размерах и когда он доходит до лимитов первого > > устройства что происходит? > > я не замечал что бы у меня mhddfs что то переносил автоматом при > увеличении > > файла, да и разделять файл на куски он не умеет, у самого в там > фейкрайде 8 > > устройств по 700-800 гб > > > ____ > > Munko O. Bazarzhapov > > JabberID: v...@aginskoe.ru > > mail: vec...@gmail.com > > > 15 апреля 2016 г., 0:03 пользователь Pavel Shurubura < > > pavelshurub...@gmail.com> написал: > > > Спасибо за ответ. > > lvm - пробовал - для дома это overhead. > > raid 0 - там по моему размер дисков должен быть одинаков (или всё > > выравнивается по минимальному), а у меня: 500Gb, 2 Tb, 1 Tb. > > А unionfs - это не то? Стоит смотреть? > > И ещё вопрос: на x64 mhddfs будет стабильнее? > > > 14 апреля 2016 г., 17:53 пользователь Yuriy M. Kaminskiy < > > yumkam+deb...@gmail.com> написал: > > > Pavel Shurubura <pavelshurub...@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: un...@debian.org jabber://un...@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----- > >
