Re: Gmane потихоньку умирает...

2016-08-22 Пенетрантность Oleksandr Gavenko 
On 2016-08-22, Dmitry Derjavin wrote:

> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>
> Там же основные проблемы были из-за web-интерфейса. NNTP точно
> останется.

Я попал на даунтайм позавчера. Потому искал альтернативы.

Обновил страничку https://wiki.debian.org/UseNet

В общем:

  linux.debian.* - gateways to debian-*@lists.debian.org 

По идее это пробрасывание в mail серверах проекта Debian настроено.

> Жалко было бы permalink, но, думаю, и его подхватят.

У меня в блокнотике где то 70 шт. Из Archived-At выдирал вместе с текстом, что
бы по необходимости вернуться к дискусии.

-- 
http://defun.work/

Re: Gmane потихоньку умирает...

2016-08-22 Пенетрантность Dmitry Derjavin 
Пн, 22 авг 2016, 19:29, Oleksandr Gavenko:

>   https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/

https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502

Там же основные проблемы были из-за web-интерфейса. NNTP точно
останется. Жалко было бы permalink, но, думаю, и его подхватят.

-- 
~dd

Gmane потихоньку умирает...

2016-08-22 Пенетрантность Oleksandr Gavenko 
Пояснения автора:

  https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/

Мне нравилось что можно ранее прочитаные статьи подгружать (по Message-ID
из References).

Gnus восстанавливал нить разговора.

С подпиской в рассылку не понимаю как подобный workflow организовать, потому
как прочитаные письма я почти всегда удаляю.



На news.eternal-september.org есть группа linux.debian.user.russian с
содержимым https://lists.debian.org/debian-russian/ как говорится на:

  https://www.debian.org/support#usenet

Т.е. можно продолжать следить за рассылкой не подписываясь и не фильтруя
письма по каталогам.

-- 
http://defun.work/

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

2016-08-22 Пенетрантность Munko O. Bazarzhapov 
А что сейчас актуальное можно опробовать что бы тупо пространство из
смонтированных папок склеивать, пару месяцев пробежался, почти все
заброшено, unionfs или aufs были какие то проблемы с очередностью записи
наследие от squashfs вообще не устраивается у меня логически в голове если
точек монтированя делать больше 3 (у меня например тестовый стенд из 8
точек с разными объемами)


Munko O. Bazarzhapov
JabberID: v...@aginskoe.ru
mail: vec...@gmail.com

22 августа 2016 г., 21:03 пользователь Dmitry E. Oboukhov 
написал:

>
> Проект заброшен, а 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  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 Гб) всё
> >> остальное пропадает...
> >> т.е. показывает,

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

2016-08-22 Пенетрантность Dmitry E. Oboukhov 

Проект заброшен, а 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 
> написал:

> в настройках качалки есть опция что бы при скачивании сначала создавал для
> закачки все файлы соответственно размерам и только после этого начинал
> закачку?
> торрент без этой опции создает файл размером несколько сегментов (допустим
> 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  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: патч *не проверен*, я не

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

2016-08-22 Пенетрантность Munko O. Bazarzhapov 
В общем за время пользования почти в 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  написал:

> в настройках качалки есть опция что бы при скачивании сначала создавал для
> закачки все файлы соответственно размерам и только после этого начинал
> закачку?
> торрент без этой опции создает файл размером несколько сегментов (допустим
> 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  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,...? Оно,