Это копия, сохраненная 5 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Планирую делать полноценный «дэйта-сэнтр» в домашних условиях.
Далее будут приведены цели и ПО, которое планирую использовать.
Скажи, если для чего есть лучшие альтернативы.
ОС: RHEL
ФС: BTRFS (RAID1 -> RAID10)
стриминг видео с декодированием на сервере: jellyfin
файлопомойка с синхронизацией телефона: nextcloud
стриминг аудио с кешированием на устройстве: airsonic
VPN: wireguard
торренты с автораспределегием по директориям: rtorrent
веб сайты: пока не знаю, потом прикручу контейнеры
* контейнеры: Docker
Все норм?
> торрент
Почему не легковесный Transmission?
> OS
Я бы посоветовал какой-нибудь FreeNAS. Местные аноны в этом плане лучше подскажут, но RHEL явно не твой выбор
Да и вообще ниже есть целый тред по насам, спросил бы там
>не трансмишн
Не умел следить за директориями, когда я проверял.
>есть тред
Извиняюсь, просмотрел.
Пойду туда.
>не RHEL
Почему? На фринас даже джеллифина нет.
>rtorrent
Отличную машинку для майнинга собрал.
https://www.opennet.ru/opennews/art.shtml?num=48177
> Атака производится когда пользователь открывает в браузере подконтрольные злоумышленнику страницы на системе в которой также выполняется rTorrent.
Не актуально для меня.
Ну и если знаешь другой клиент, который следит за директориями и автоматически качает по нужным путям, могу перейти на него.
Я помню, что смотрел на неё лет 5 назад, но не смог прикрутить мониторинг директорий.
Попробую снова, спасибо.
Из ценного будут архивы и модели по научной работе.
Ну и старые семейные фото.
Остальное не хотелось бы терять, но не критично.
Ну и мусор вроде фильмов и музыки, да образов всяких.
Это ебучее говно на питоне с постоянными проблемами при обновлении и самым медленным пакетным менеджером?
Не говоря уже о том, что OpenRC это чуть ли не самый медленный система инитов.
Спасибо за рекомендацию, но нет.
Лучше уж NixOS обмазаться.
Тоже верно.
Теперь либо БСД, на который не все портировано пока либо СистемД.
>>04995
Пакеты начали сегфолтится, очень многое стало значительно дольше обновляться.
Новый хэндбук просто крупная Параша по сравнению даже со старыми доками.
Форум убрали.
Глав. Девы с самомнением уровня разработчиков ГНОМ, хотя по сравнению с экстремом не сделали и 10 части все вместе.
Единственный плюс за последний год- 64-битный вайн.
>NAS
>RAID10
>торренты
Паршивая идея.
>>04825
>Ну тогда тебе нужно ECC Ram
Не нужно. "Scrub of death" - полумифическая хрень, наблюдать которую у тебя шансов не больше, чем восстановить случайную строку по ее sha256-хэшу с одной попытки.
>>04826
>и хотя бы raidz2
Для дисков <= 4ТБ не имеет смысла.
>BTRFS
>RHEL
Слабоумие и отвага.
>>05016
>но заводить ZFS на лине это такое себе.
Оно прекрасно работает.
>работает
А теперь назови хоть одну причину использовать костыли вместо ФС в ядре, которая умеет все то же, что и ЗФС и даже больше.
Хотя лучше раскрой мысль про RAID10 и плохую идею.
>Почему?
Потому что будешь скрежетать головамии всех дисков в массиве 24/7. Дорогое и бессмысленное удовольствие с точки зрения как амортизации, так и безопасности данных. Под скачку-раздачу торрентов лучше завести отдельный бросовый диск, который можно без проблем заменить, когда загнется.
>Здесь по 14 будет
Тогда да, либо raidz2, либо автоматическая репликация куда-нибудь во внешнее хранилище. И диски без черепичной записи, иначе ребилда массива не дождешься никогда.
>но заводить ZFS на лине это такое себе
Несколько лет уже, как полностью перешел на ZFS везде, где только можно (суммарно около 20 машин различного назначения). Все работает идеально, ни единого косяка.
>Потому что будешь скрежетать головамии всех дисков в массиве 24/7.
Разумно.
Хотя скрежетать должно только при скачивании и записи.
Раздача должна активировать только диск(и) с данными.
Тогда RAID1, наверное.
>внешнее хранилище
Я понимаю, что реданданси это не бекап, но предпочёл бы обойтись одним устройством.
Потому и рассматриваю варианты с0 100% redundancy, чтобы если уж даже половина дисков наебнулась, то данные остаются.
Хотя за всю жизнь у меня только один дешевый ВД отказал.
>работает
И все же, какие плюсы перед BTRFS?
Последний нативен, активно поддерживается и имеет дополнительные плюшки.
>Хотя скрежетать должно только при скачивании и записи.
>Раздача должна активировать только диск(и) с данными.
Нет. Раздача - это как раз основной источник стресса. Данные в RAID-массиве хранятся чанками по 128KB. Теперь представь, что размер блока данных твоего торрента - 4МБ. Это значит 32 чанка. В случае RAID1 из 2 дисков это будет по 16 обращений к каждому диску. И так на каждый блок данных, а L1/L2 кэши в случае торрентов тебе вообще никак не помогут.
>Я понимаю, что реданданси это не бекап, но предпочёл бы обойтись одним устройством.
Я предпочитаю локально иметь raidz1-массивы из небольших дешевых 4TB-дисков для обеспечения скорости и разумного времени перестройки + репликацию на большой внешний диск без резервирования, подключенный к обычному одноплатнику.
>И все же, какие плюсы перед BTRFS?
Не знаю. В тот момент, когда я перекатывался на CoW-системы, btrfs был кривой и толком ничего не умел. ХЗ, как там сейчас дела обстоят.
> Раздача - это как раз основной источник стресса.
Неприятно.
Но спасибо за информацию, тогда буду думать, что и как изменить.
Хотя удивлён, если честно.
Дома стоял Synology с перманентно включёнными торрентами и вроде был достаточно тих и неприхотлив.
Вот уже почти 5 лет как онлайн с одним диском и все норм.
>4Тб
Вариант, но я хочу максимально компактно все сделать.
Как результат— могу поставить до 6 дисков и нужен большой объём.
Как часто у тебя выходят из строя носители?
>когда вкатывался
Тогда понимаю.
Сам читал много жалоб, но следил за проектом и уже пару лет как все хорошо и даже доп. фичи потихоньку внедряют.
Тот же Synology на BTRFS, например, хоть и с кастомными патчами на древнем ядре.
Вообще, я бы bcachefs попробовал, но он ещё даже не в ядре.
1. Камон, какие костыли, оно из коробки идет уже.
2. Брбрфс, серьёзно? Мне нужно объяснять какое это говно говна с амплификсцией записи 40х?
Не будь идиотом. Используй лучше lvm + xfs/ext4 или вообще аппаратный рейд.
>из коробки
>OpenZFS 2.0 вышел меньше месяца назад
>никогда не добавят в ядро
Ну, я даже не знаю.
>говно говна
Объясни. Я давно пользуюсь для внешних дисков и действительно не в курсе.
>изначально меньше контроля
>контроллер наебнулся
>вжух и ты пидор
Напомни, какие плюсы у такого решения?
>Для дисков <= 4ТБ не имеет смысла
Почему, и как вообще parity связано с размером диска?
А насчет ECC, ты думаешь он просто так стоит в любом сервере? И не забывай, что при async записи ZFS кладет все в рам а потом скидывает на диск, там то и сожет случиться косяк, ну или во время resilver. Ошибки РАМа это частое явление, прост без ECC ты о них не знаешь.
https://serverfault.com/questions/26483/statistics-on-ram-malfunction
>И все же, какие плюсы перед BTRFS?
btrfs не умеет в raid5/6
btrfs глючное гавно которое может рассыпаться в любой момент
1. Умеет, но проблема с write hole не решена, это да
2. ZFS не умеет в RAID10, который для меня значительно актуальнее.
> btrfs глючное гавно которое может рассыпаться в любой момен
Голословно. Пруфы есть?
Там и raid5 нету, технически, творобушек ты тупой.
Кому в здравом блядь уме нужен "технически RAID10" когда ZFS предоставляет более крутые механизмы с большим функционалом?
Брбрфс кстати имеет теже ограничения, если я верно помню.
>Это уже другой вопрос, но факта это не меняет.
В зфс, как и в брбрфс, технически нету никакого рейда. Это факт.
Ваш Капитан Бесполезный Факт.
>Голословно. Пруфы есть?
В гугол лалка. Олсо отчем мы вообще говорим если спустя больше 10 лет fsck так и не допилена?
> fsck
потому что вместо неё btrfs-check
https://github.com/kdave/btrfs-progs/blob/devel/Documentation/fsck.btrfs.asciidoc
> В гугол лалка
Гугл выдал это:
https://btrfs.wiki.kernel.org/index.php/Production_Users
> Facebook (testing in production as of 2014/04, deployed on millions of servers as of 2018/10)
https://code.fb.com/open-source/linux/
И? Пейсбук может делать вообще что угодно. У них куча реплик и при какой либо проблеме они могут кинуть с десяток скилованых инженеров ее разруливать. Тв будешь покупать два или три наса? У тебя есть челы которые по щелчку пальцев пойдут ковырять ядро?
https://www.suse.com/support/kb/doc/?id=000018769
>If this does not work, start the repair procedure.
WARNING: Using '--repair' can further damage a filesystem instead of helping if it can't fix your particular issue.
Ensure a backup has been created before invoking '--repair'. If any doubt open a support request first, before attempting a repair. Use this flag at your own risk.
Ну да, хороший чек, ниче не скажешь, лол.
Каким образом твои скриншоты это показывают, болезный?
>If this does not work, start the repair procedure.
Логично, значит разделу пизда
> Ensure a backup has been created before invoking '--repair
Тоже логично
Всё ещё не делаешь бэкапы?
Я понял почему ты сопротивляешься, потому что все перешли, а Apple не перешла.
Память не знаю, ФС там BTRFS.
Пейсбук
>>06515
https://www.reddit.com/r/linux/comments/kieqyu/warning_linux_510_has_a_500_to_2000_btrfs/
>Warning: Linux 5.10 has a 500% to 2000% BTRFS performance regression!
>Новое LTS ядро
>проблемы
>2000% performance regression!
>нормально работает на прошлых ядрах яскозал
> LTS, это не значит что оно долго будет иметься в виду, это значит что оно стабильное в релизе
Погоди, оно только 9 дней назад высралось, сейчас ещё найдут кто-где срал и в продакшн
Ну такое, чек с репейром делает еще хуже. Серьезно? Может с чеком что то не так все таки?
моча хуле тут банишь, глотай сперму своего папаши.
Дорогой, кто такои все, ну кроме пейсбука и сайнолоджи ?оба кстате полнейшее гавно. Нам на аппле брбрфс нинужон, есть нормально работающая APFS. А дома на TrueNas MiniX отлично работает ZFS.
Ставь TrueNAS + ZFS. В bhyve поднимешь линокс и бушь гонять там докер.
Вам вообще ничего ненужно, даже запоминать пароли, нажал галочку и система показала его плейнтекстом, если забыл.
>пикрил
Чет сильверстоун в край обленились, поменяли морду от SG 13 и воткнули шасси - насик готов!
>FreeNas
Однозадачная коляска, если руки из нужного места, то проще самому все настроить на любой системе (хоть линь, хоть бздя, хоть солярис какой нить)
Да просто так.
В btrfs есть копи он врайт (как в варе; сразу вспоминается - если хочешь иметь проблемы с созданием снэпшота, выбирай хв, если с удалением - вару) и б-деревья.
Ни первое, ни второе не будет нужно на нас.
Первое нужно там, где есть требования по ревизиям снимков данных и если это меньше 300тб, то это скорее решается бэкапом, а второе нужно - где данных много.
Если уж хочется чего-то не дефолтного, то и правда zfs.
>>07794
Если opennas, или truenas могут в докер, то самое разумное, имхо.
Я в итоге на другом корпусе остановился.
У сильверстоуна (и большинства альтернатив) кулер далеко от дисков расположен и люди жалуются на температуры.
В итоге жду U-NAS NSC-810 в продаже.
>>18316
“Стабильность”, снепшоты и нативная поддержка нескольких уровней RAID.
А, ещё драйвер для виндоус. Некоторые даже винду с него запускают в виртуальной.
>кулер далеко от дисков расположен
Жёсткие диски не надо охлаждать. Особенно в насе, где они простаивают 95% времени.
Канешн не надо, пусть до +55 кочегарятся. По твоему же пикрилу видно, что в идеале +35+45.
>простаивают
Напоминаю, что там будут торренты (вне массива, скорее всего) и медиа-серверы.
Так что диски будут греться более чем.
>По твоему же пикрилу видно, что в идеале +35+45.
Средний винт без обдува и висит в интервале 30-35. Пикрел мой медиацентр-сидбокс у батареи без какого-либо обдува.
До 50 реально самые запущенные валенки кипятятся.
Мы же тут вроде домашнюю файловую помойку собираем, а не что-то для работы со снепшотами виртуальных машин и/или еще чем-то. Помои можно, и имхо, нужно хранить на mdadm+ext4. Скорость доступа выше чем у ZoL/BTRFS, а что еще нужно неискушенному пользователю?
Почему бесполезен и зачем ты мешаешь LVM с BTRFS?
>без виртуалок
Но с контейнерами.
Лично я беру BTRFS, потому что из коробки максимально просто собрать нужный мне RAID1/10 и может в дедупликацию, расширение массивов и все прочее.
Какой плюс от использования отдельной утилиты (mdadm), если ФС нативно все поддерживает?
Ну и у меня личная неприязнь к EXT4, после того, как у меня умудрились закончиться иноды при нормальном использовании ПК.
>Жёсткие диски не надо охлаждать. Особенно в насе,
Люди жалуются на 65 градусов Цельсия.
Это не здорово.
>может в дедупликацию
Эм. Он может только если ты руками сказал: чувак хочу дедуплицированную копию вот этого образа. На лету как зфс он не умеет. А те костыли которые делают это сбоку лучше бы вообще ничего не делали.
Может и имеет смысл.
У меня около 5 лет файловая помойка жила на nfs + mdadm из 4 винтов, бед не знал, даже без упса. Пережила много отключений электроэнергии, рейд так и не развалился.
Так же крутил там minidlna / transmission-daemon / owncloud / strongswan + xl2tpd. Бед не знал.
В прошлом году купил синьку ds920+. ВПН сервер переехал на vyos.
У меня, кстати, тоже не поднимается выше 30 градусов даже при нагрузке.
Там постоянная нагрузка, без обдува изи под 50 улетают.
Всё что касается ФС должно быть масимально дефолтным. Каждый дополнительный слой увеличивает шансы что всё распидораится, что никакие утилиты не помогут. Лично я в хранилищах пришёл к схеме:
1) ext4
2) raid/mdadm дома не нужен, только на продакшн серверах для минимизации простоя
3) lvm нужен только если планируешь склеивать больше одного винта, или добавлять диски
4) бэкапы borgом на другой винт, или на другое хранилище, не забывать чекать здоровье по хрону
5) шифрование в отдельных контейнерах если шибко надо
7) PROFIT
В результате даже если я внезапно потеряю бэкапы, у меня останется куча инструментов по разруливанию ситуации от ддрескью и тестдиска до платной рстудио.
Если у тебя нет задачи которую может решить ZFS - ставь mdadm + ext4. Отлично работает. 5 лет работы моего прошлого наса не дадут спиздеть.
Можно вообще въебать говна и купить аппаратный рейд-бокс на али и подключить его к роутеру по USB3
>Что, блядь?
https://www.r-studio.com/ не путать с https://rstudio.com/
Отлично работает с ext4. На резонный вопрос: "на кой это надо, если есть тестдиск" отвечаю.
1) Коллеги не раз говорили, что он больше файлов достаёт.
2) Лично я могу подтвердить, что он работает в несколько раз быстрее.
3) Доступный, его можно поручить любой эникейной обезьяне.
В общем достойный продукт за свои деньги.
Ну rstudio это классический open-core, и у него тоже энтерпрайзная версия есть.
>Но с контейнерами.
Пяток контейнеров же. Их конечно очень часто снэпшотить надо. Прям поддержка от фс нужна.
1. Почему ты хочешь redhat? То, что ты собираешься нагородить, в ней будет сделать сложнее.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs
2.
https://docs.docker.com/storage/storagedriver/btrfs-driver/
Докер не советуют использовать brtfs, кроме оговоренных условий. И если уж брать эту фс, то только под контейнеры. А не под и то и пятое и десятое.
3. Я могу предположить, что выбор пал на redhat, т.к. кубернеты, но тогда пункт 1.
> Их конечно очень часто снэпшотить надо. Прям поддержка от фс нужна.
А кто будет снэпшотить изменения в файлах? А так хуяк, откатил изменения в файле из снапшота и в хуй не дуешь.
>почему редхат
Хотел CoreOS, но из пожрала федора.
С Фёдором знаком хорошо, а заодно и ключ на RHEL имею.
Потому и решил ее.
Кубернеты активно рассматриваю.
>FHS
Так для ОС и всех контейнеров там ССД на терабайт.
На нем будет XFS, а массивы примантированны к контейнерам.
>почему BTRFS
Нативная работа с многими дисками и нужные уровни RAID.
>условия
Вроде по все подхожу, кроме рекомендованной ОС, но это лишь рекомендация.
С софтовым рейдом на десктопном железе проблем на свою жопу можно нажить только больше. Я уже не говорю о большом количестве случаев отваливания рейда. Чуваки с unraid не дадут соврать.
Гурман, однако.
>проблем
Каких?
Да и железо относительно недесктопное (особенно мать).
>отвалиться
Разве что вся ФС полетит, но за всю жизнь такого не испытывал.
Если у тебя есть ECC память и нормальная сервер-грейд мать тогда можешь воротить, что душе угодно.
Вот попадалось как-то забугорное обсуждение, что ECC не хуй то и нужно в том же zfs для домашнего применения, ибо вероятность ошибки накопителя несоизмеримо выше ошибки ДО накопителя, в рам в частности.
Так и есть
Сама система менеджмента контейнеров. Она может использовать фичи фс. Но тут, как мне кажется, не тот случай, чтоб этим заморачиваться.
>>18488
> активно рассматриваю.
> Так для ОС и всех контейнеров там ССД на терабайт
Ясно.
> а массивы примантированны
Т.е. в сухом остатке имеем именно:
"Нативная работа с многими дисками и нужные уровни RAID."
Т.е. к контейнеру ты будешь монтировать вольюм? Или через bind?
Хорошая, годная статья для выбора софт рейда.
Хорошая, годная статья для выбора софт рейда.
Я бы хотел биндить, но поскольку мне нужно несколько контейнеров к одному пулу дисков, думаю, придётся вольюмами.
Пока эта система только для меня, но надо ещё подумать, как потом распределять доступ.
Возможно, у подмана с этим лучше?
>>18733
Повторю, что говорил выше: «если нужна только файлопомойка, то синолоджи— отличный вариант».
Если нужно хоть что-то ещё, то это лютый проглотим. Там даже с FFMPEG трудности.
Я уж не говорю про БТРФС на ядре времён палеозоя.
> Там даже с FFMPEG трудности.
Хоспади, один забэкапить а на его место симлинк от правильного хуйнуть. Проблема блять!
Синолоджи все таки умеет в айскази, а там уже средствами системы можно и снапшоты и все, что в голову придет. Не стоит так относится к home grade nas.
FreeNAS + zfs + openvpn. Вот настоящий топ.
Тебе википедии не хватает?
Позволяет блочное устройство подключать по сети.
Тип не папочку с файлами а диск, как диск, который ты можешь форматровать во что хош и установить туда ОС.
Юзкейсы - ну например виртуализация и бесдисковые станции. А так же всевозможные SANы.
SAN это когда у тебя диски в одной комнате управляемые централизованно, а сервера в другой.
>А почему все так дрочат на btrfs?
Кто все блядь?
Его если что ВСЕ поливают говном. Потому что это глючное говно с амплификацией записи 40х.
>Making rounds this week was word of a "500~2000% performance regression" knocking Btrfs on Linux 5.10. For a simple test case like extracting a large .tar.zst file could go from taking just around 15 seconds to nearly five minutes or in other cases like from 5 seconds to over 30 seconds. The regression was bisected to a fundamental Btrfs change in Linux 5.10 and reproduced on bare metal while running Btrfs within a virtual machine didn't trigger the major slowdown.
И что? Выбранный из жопы никому не понятный архив zst плохо работает в btrfs. Да кого это ебёт вообще? Это проблемы zst.
> Я бы хотел биндить, но поскольку мне нужно несколько контейнеров к одному пулу дисков, думаю, придётся вольюмами.
Т.е. ты поверх brtfs будешь создавать блочные устройства со своей фс внутри?
Бывают битые плашки, которые дают одну ошибку на 50 прогонов. Самый хуёвый вариант, такие хер отловишь, пока мемтест на неделю не оставишь.
Ну т.е. ладно, забыли про контейнеры. Для них бртфс тебе не нужна.
У тебя есть 1 диск под систему, 4 под рэйд 10 с семейными фото, 1 под торренты. Диски - это около 60к рублей, еще 20 - под считалку. Т.е. 80к под нас с семейными фото, я ничего не упустил?
У меня дороже стоит и там контент такого же уровня. Не считая бэкапы всех устройств домашних.
Молодец, эффективно.
Кстати, а бэкап на какую фс кладётся? В xfs есть блок клонинг, наверное для бэкапов удобно. Ну, или refs.
> файлопомойка с синхронизацией телефона: nextcloud
Эта хуйня заприватит шареную папку и доступ к ней будет только через него. Если ты хочешь в те папки ходить свободно, расшарь по самбе и подключи как внешнее хранилище.
>блочные устройства
Нет.
SSD: XFS -> ОС, контейнеры, все прочее
HDD: BTRFS RAID1/10 -> все данные
У докера есть драйверы для нативной работы с BTRFS.
Сейчас почитал про вольюмы побольше, от них действительно будут некоторые неудобства.
Хотя, если РЭЙД сделан средствами самой ФС (как в моем случае), то никаких проблем быть особо не должно.
Тогда смотрю, можно ли нескольким контейнерам без проблем забиндить диски.
Упустил, перечитай ОП.
Мне нужны ещё 2 медиа сервера и некстклауд для телефона.
Скорее всего, ещё бекары для моих компьютеров через BORG или что-то похожее.
Не знал, почитаю об этом, спасибо.
А сколько всего дисков? Штук. Мне правда интересно как насы используют.
И сколько лет это все у тебя работает?
У меня есть опосредованный опыт с brtfs, про частные облака, там выделяли специальную команду из нескольких человек под это. Примерно как сторадж команда, но их специфика была - сбор перформанс метрик. Дитрейс с рестапи, если образно говорить. Т.е. это скорей сириуз бизнес.
И есть прямой опыт с ZFS с прошлой работы, однако как-бы не совсем опыт. У меня никогда ничего не случалось. Но там и данные не клиентов лежали, а внутренние. Единственный опыт - следить за тем, чтобы кондиционер не забывали включать летом, а то можно в понедельник нескольких дисков недосчитаться.
У синолоджи есть коробки с разъемами под SSD, но они искользуются не как пространство для хранения, а как кэш.
При использовании в одно рыло, ты не почувствуешь разницы по гигабитной сети.
Усложняешь, просто перекидывай файлы с ссд на хард через rsync в кроне. Если речь о торрентах, большинство торрент-клиентов умеют сначала качать в одну папку, а потом перемещать в другую
Я оп пост читаю так - есть примерно 4 типа данных.
И надо выбрать политику хранения. Подойдёт ли brtfs c рейд 10?
>>18958
Сначала я подумал, что brtfs тебе нужно для контейнеров. И я позволил себе усомниться, что для пятка контейнеров это принесет что-то ощутимое.
Потом оказалось, что не для этого, а просто для рэйда средствами фс.
Дальше вывод такой - для 4 типов данных, политика, которая просто подазумевает какой-то один тип рейда, это странное решение. Так можно сделать, вопросов нет. Если ты хочешь на все данные накатить такую-то политику и brtfs позволяет эту политику реализовать - гоу он. Вопрос только в том почему ты выбрал такую политику. А этого как раз в оп посте нет.
>>18967
Да.
Под виндоус - rapid storage technology.
У эппл - Fusion.
Linux - Bcachefs.
Про виндоус - не советую, под мак - уже не нужно, под линукс - не пробовал.
Спасибо за совет, bcachefs кажется то что я хотел.
Никаких проблем не наблюдал. Даже если свет отваливался в те времена когда упса еще не было.
>Я оп пост читаю так
Возможно, я плохо передал мысль.
Там больше вопрос про все остальное был.
То, что БТРФС подходит я знаю, так как давно пользуюсь им для всего, что не внутренний системный SSD.
>политику
Не совсем тебя понимаю.
Файлы они и есть файлы.
Вопрос не столько к ФС, а к правильному доступу к ним.
То есть как правильнее реализовать доступ к одному файлу из нескольких контейнеров одновременно и чтобы это работало.
Конечно, условные видео и аудио сервер не должны иметь доступ к одному и тому же файлу, но вот Nextcloud должен иметь доступ к аудио, например.
Не совсем понимаю, зачем разделять по дискам, если использовать весь массив как одну ФС звучит для меня более логично.
>Выбранный из жопы никому не понятный архив zst плохо работает в btrfs
>The regression was bisected to a fundamental Btrfs change in Linux 5.10 and reproduced on bare metal while running Btrfs within a virtual machine didn't trigger the major slowdown
> То есть как правильнее реализовать доступ к одному файлу из нескольких контейнеров одновременно и чтобы это работало.
bind конечно.
С точки зрения высоколобых рассуждений, тебе нужна кластерная фс для контейнеров. Т.е. контейнеру ты представляешь блочное устройство, внутри контейнера есть сервис, который обеспечивает работу кластерной фс и пирится с этим сервисом из другого контейнера. Которому ты предоставил это-же блочное устройство. Можно на нас накрутить, но выглядит смешно.
На самом деле - нет в этом потребности. Ну есть исчезающая вероятность, что контейнер1 с торрентом и контейнер2 с медисервером там что-то неподелят, рестартуешь контейнер и всё. Так просто не принято делать, принято запихивать торент и медиасервер в одну сущность, это обкатано. А как поведёт себя докер в твоих условиях - плохо обкатано. Т.к. контейнеры не совсем для этого делали. Весь реальный i/o будет на редхате, там все будет хорошо, а что случится с контейнером при локах фс, поверх которой докер бинд - да чёрт его знает. Рестартуешь контейнер - проблемы нет.
>>политику
>Не совсем тебя понимаю
Я просто смотрю с привычной для себя точки зрения.
Вот есть машина с субд, а есть машина с файловой шарой.
Эти машины будут иметь разный паттерн i/o. И то что хорошо для одной - излишки для другой. Или даже плохо для другой.
Политика - это когда ты говоришь, вот первую машину хочу на быстрых дисках и таким-то резервированием, а вторую - можно диски помедленнее и с другим резервированием.
Давай к примеру торенты? Вот ты собираешься их класть на рейд. Зачем? Тебе эти данные даже бэкапить не надо. А когда ты их туда кладёшь, это приводит к значительному оверхеду с точки зрения контроллера диска.
Записная книжка. Если тебе нужно непрерывное использование - рейд нужен. Вместе с бэкапом. А если день без синка ты проживёшь, то тебе не нужен рейд, а нужен только бэкап.
Конечно для дома на 8 дисках реализовать все возможные политики не выйдет. Но выбирать политику, которая подразумевает рейд 10 для твоих данных - странно.
> То есть как правильнее реализовать доступ к одному файлу из нескольких контейнеров одновременно и чтобы это работало.
bind конечно.
С точки зрения высоколобых рассуждений, тебе нужна кластерная фс для контейнеров. Т.е. контейнеру ты представляешь блочное устройство, внутри контейнера есть сервис, который обеспечивает работу кластерной фс и пирится с этим сервисом из другого контейнера. Которому ты предоставил это-же блочное устройство. Можно на нас накрутить, но выглядит смешно.
На самом деле - нет в этом потребности. Ну есть исчезающая вероятность, что контейнер1 с торрентом и контейнер2 с медисервером там что-то неподелят, рестартуешь контейнер и всё. Так просто не принято делать, принято запихивать торент и медиасервер в одну сущность, это обкатано. А как поведёт себя докер в твоих условиях - плохо обкатано. Т.к. контейнеры не совсем для этого делали. Весь реальный i/o будет на редхате, там все будет хорошо, а что случится с контейнером при локах фс, поверх которой докер бинд - да чёрт его знает. Рестартуешь контейнер - проблемы нет.
>>политику
>Не совсем тебя понимаю
Я просто смотрю с привычной для себя точки зрения.
Вот есть машина с субд, а есть машина с файловой шарой.
Эти машины будут иметь разный паттерн i/o. И то что хорошо для одной - излишки для другой. Или даже плохо для другой.
Политика - это когда ты говоришь, вот первую машину хочу на быстрых дисках и таким-то резервированием, а вторую - можно диски помедленнее и с другим резервированием.
Давай к примеру торенты? Вот ты собираешься их класть на рейд. Зачем? Тебе эти данные даже бэкапить не надо. А когда ты их туда кладёшь, это приводит к значительному оверхеду с точки зрения контроллера диска.
Записная книжка. Если тебе нужно непрерывное использование - рейд нужен. Вместе с бэкапом. А если день без синка ты проживёшь, то тебе не нужен рейд, а нужен только бэкап.
Конечно для дома на 8 дисках реализовать все возможные политики не выйдет. Но выбирать политику, которая подразумевает рейд 10 для твоих данных - странно.
>тогда бинд
Хорошо, спасибо тебе.
>торренты
Их как раз теперь планирую на отдельный диск вне рейда, так как анон выше сказал, что пихать их в основной рейд— крайне тупая идея.
То есть качается через VPN-контейнер на Диск 8 и, по завершении, копируется в основной массив (диски 1-6), чтобы (1) все было лучше рассортировано и (2) к этому получили доступ нужные контейнеры.
RAID10 выбирал, потому что это тот же рейд1, только быстрее и с некоторыми оговорками.
Хотя сейчас не уверен, что с моим юз-кейсом есть смысл в чём-то кроме RAID1.
Просто планировал расширять массив (начать с 4 + 1, потом 6+1+1), а при RAID1, если я правильно понимаю, это будет 2 массива.
> в чём-то кроме RAID1.
А почему ты так считаешь? Большая часть треда как раз об этом. Всякие буковки и аббревиатуры - это про почему рейд 1/10, неважно на чём реализованный.
Вопрос без всяких экивоков.
Я бы по работе сказал, что 5-ка нужна. Для дома -1-цу, т.к. рубли/гигабайт не считал бы и обслуживание сведётся к - работает/нет.
Но у меня дома нет нас и интересно знать твои критерии.
> при RAID1, если я правильно понимаю, это будет 2 массива.
Я на данный момент вижу твою хотелку так:
а)xfs под систему
б)2 диска под raid1, средствами brtfs
в)1 диск под торренты, средствами brtfs
Ты можешь докинуть 4 диска и засунуть их в пункт с рэйдом.
Забавно, что когда ты говоришь массив - у меня возникает путаница - что именно ты имеешь ввиду. Для меня массив - это дисковая полка и контроллеры. Ну питание может ещё. Это используют для того, чтоб поверх потом построить другую сущность. Обычно в линуксах это pv, или результат работы mdadm. Или пул у зфс. Т.е. до самой файловой системы еще не дошли.
Но поскольку у тебя бтрфс, это просто набор блочных устройств. Т.е. если у тебя 2 фс, одна под рейд, другая под торренты, то у тебя "2 массива", угу. Я не знаком с терминологией, когда btrfs поверх голых дисков разворачивают. Наверняка ты прав и там это называют массивом. Просто мне привычнее это слово в чуть-чуть другом контексте использовать.
Получается если проебать базовый снимок то и всем снепшотам пизда?
Я не знаток btrfs, но советую загуглить скриншоты snapper из sles, там будет всё очень похоже на то, как у гипервизоров. В потрохах тоже будет снэпшот-ид, а что там еще глубже, я не знаю.
Еще можешь сравнить COW и ROW подходы по снэпшотам, чтобы четче понимать про какую дельту ты говоришь.
Там CoW, там вообще всё это дельта состояний.
>Получается если проебать базовый снимок то и всем снепшотам пизда?
Как ты его проебать собрался? dd напрямую в блочный девайс?
Угу.
Я читнул про дедуп в этой битриэфэс.
Он там реально нужен, чтоб между снэпшотами дедуплцировать - https://github.com/lakshmipathi/dduper
А для контейнеров это использоваться не будет, т.к. юзеркейс не предпологает снэпшты контейнеров. Все данные - вне контейнеров.
>которые делают это сбоку лучше бы вообще ничего не делали.
Дедуп в привычном смысле - https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe
Т.е. год назад - это блидинг эдж патчи, с ram непонятно, но не как на нас устройстве. Ну и квоты теряем на деле.
Такой танец на рэдхате проворачивать я бы не рискнул.
Рискну предположить, что это главный предмет головной боли суппорта synology.
>А для контейнеров это использоваться не будет
Докер при копировании слепка указывает, что копирование с дедупликацей. В итоге с кучей однородных образов выгода достойная.
> Докер при копировании слепка указывает, что копирование с дедупликацей.
Что ты имеешь ввиду? Мой поинт был простой - комит, или чекпоинт - это никак не затронет данные, которые к контейнеру подмонтированы. Напомню, сами контейнеры у нас на xfs, данные на btrfs.
А у тебя докер копирует слепок..
Пусть контейнер лежит на btrfs.
Попробуем погадать.
Сам докер копирует? Наверное, да.
Слепок это docker checkpoint, правильно?
Т.е. сам процесс докера вызовет ioctl_fideduperange при записи файлов на btrfs? Правильно понял?
Как ты прямо. Зашёл и заполнил собой весь тред.
>>Попробуем погадать.
>Тред идиотов полон.
Ух как ты меня!
> Докер при копировании слепка указывает, что копирование с дедупликацей.
Так что там докер копирует?
Для дедупа нало использовать ioctl_fideduperange.
Источник - https://btrfs.wiki.kernel.org/index.php/Deduplication
Вот сам докер: https://github.com/docker/docker-ce
Делаем полнотекстовый поиск против "ioctl_fideduperange" и единственное место, где встречается:
Downloads\docker-ce-master\docker-ce-master\components\cli\vendor\golang.org\x\sys\unix\syscall_linux.go
Что там?
// IoctlFileDedupeRange performs an FIDEDUPERANGE ioctl operation to share the
// range of data conveyed in value with the file associated with the file
// descriptor destFd. See the ioctl_fideduperange(2) man page for details.
func IoctlFileDedupeRange(destFd int, value *FileDedupeRange) error {
err := ioctl(destFd, FIDEDUPERANGE, uintptr(unsafe.Pointer(value)))
runtime.KeepAlive(value)
return err
}
Объявили. И всё. Нигде больше не используем. Поэтому я не понимаю что ты пытаешься донести своим:
> Докер при копировании слепка указывает, что копирование с дедупликацей.
И с радостью бы узнал, если чего-то не знаю.
>>Попробуем погадать.
>Тред идиотов полон.
Ух как ты меня!
> Докер при копировании слепка указывает, что копирование с дедупликацей.
Так что там докер копирует?
Для дедупа нало использовать ioctl_fideduperange.
Источник - https://btrfs.wiki.kernel.org/index.php/Deduplication
Вот сам докер: https://github.com/docker/docker-ce
Делаем полнотекстовый поиск против "ioctl_fideduperange" и единственное место, где встречается:
Downloads\docker-ce-master\docker-ce-master\components\cli\vendor\golang.org\x\sys\unix\syscall_linux.go
Что там?
// IoctlFileDedupeRange performs an FIDEDUPERANGE ioctl operation to share the
// range of data conveyed in value with the file associated with the file
// descriptor destFd. See the ioctl_fideduperange(2) man page for details.
func IoctlFileDedupeRange(destFd int, value *FileDedupeRange) error {
err := ioctl(destFd, FIDEDUPERANGE, uintptr(unsafe.Pointer(value)))
runtime.KeepAlive(value)
return err
}
Объявили. И всё. Нигде больше не используем. Поэтому я не понимаю что ты пытаешься донести своим:
> Докер при копировании слепка указывает, что копирование с дедупликацей.
И с радостью бы узнал, если чего-то не знаю.
>Для дедупа нало использовать ioctl_fideduperange.
Или cp --reflink.
Под слепками я понимал слои юнионфс.
Дедуплицировать персистентные данные дешево никак не выйдет.
> Под слепками я понимал слои юнионфс.
Так ты не про родной btrfs дедуп говоришь? Ну за такими скачками с одного на другое мне сложно угнаться.
Я смотрю на вводную треда - btrfs позволяет дедуп. Ни о каком докере речи пока нет.
Дальше я смотрю что именно он позволяет в этом плане.
Есть два режима работы. Один - онлайн, и как по мне - он сырой, второй оффлайн. И его действительно можно использовать. И использовать его можно эффективно, если есть много снэпшотов фс.
Дальше - если докер сконфигурировать определённым образом, он может задействовать btrfs снэпшоты. Я такого никогда не делал, судя по описанию - делать этого не советуют.
Но если сделать, то такой метод действительно позволит экономить на дедупе.
Однако в треде не предполагают, что контейнеры лежат на btrfs.
А потом появляешься ты и говоришь про совершенно другой "дедуп", который и не дедуп вовсе, а нативная докер абстракция над сторадж драйвером. И докер знать не знает что за этим стоит.
Приведет ли этот механизм к тому-же, что и родной офф-лайн btrfs дедуп? Да, но мне кажется, что в меньшей степени. Утилита для офф-лайн дедупа соберёт все чексуммы всех датаблоков. Она ничего не знает о наследовании слоёв докера.
> Дедуплицировать персистентные данные дешево никак не выйдет.
Тут спору нет.
Какое железо?
Ебать. У меня аж сердечко закололо.
Подумываю как бы дешево собраться, взять корудуба на авито или зион с али какой-нибудь, а ты мне такое сбрасывешь.
Ебать.
>>19822
И это все чтобы файлики по хранить и торенты удаленно покачать?
Часто торренты качаешь?
Что за аудио/видео стримишь?
Что за сайтик?
Отвечай.
Дайте линк на НАС-тред.
Нет никакого NAS треда. Для хранения данных достаточно даже роутера с внешним диском, далее начинаются хотелки, что для некоторых, ещё бы неплохо иметь видеокарту в сервере, например рендерить видео на серваке в подвале, чтобы не шумело в комнате.
>плюс ещё немного
>да
>БД рипы/ремуксы/диски с транскодированием на сервере.
Все мечтаю, что начнут продавать ДРМ-фри видеофайлы без региональных ограничений. Я даже фильмы покупать честно начну.
>gh.de
Просто потрясающий сайт с кучей параметров на любой вкус и ценами в Германии.
>>19105
Ты понял мою хотелку превосходно.
>почему1/10
Стопроцентный реданданси просто на всякий случай и максимальная скорость.
А BTRFS позволяет это нативно реализовать и менеджить.
>Массив
Я это как заменитель RAID использую, то есть «дисковый массив».
Да что ты знаешь о хранении данных, сынок? Нам похуй на твои поделки из говна и палок.
Отбери у тебя говнороутер от китайского ноунейма с внешним диском и что от тебя останется? Ты сможешь собрать рейд за zfs имея при себе только калькулятор? Ты сможешь сохранить данные там где им не место?
Мы будем собирать НАСы из самых дорогих комплектующих ИСКЛЮЧИТЕЛЬНО для того чтобы качать говносериалы, музыку в 64 кб\с и хранить фотографии того как дядя Петя уморительно нахуярился на своем юбилее. Ты понимаешь? Нам похуй. Средства не важны, цели не важны, важен сам путь.
Какая йоба у тебя дома стоит?
Нужно намутить сервер, с 2я эзернет портами гигабитными и вайфай, дабы был роутером, поднять джит и некстклауд, файлопомойку, по классике торрент, прокси/впн и еще что-то.
Бюджет 5-6к на все про все, без учета дисков.
Присматриваюсь к авито-говну на лга771 сокете, кор2квад/зион, но я вот хуй знает как выйдет по интерфейсам. Хуй знает как это все прикрутить, вайфай/эзернет можно через usb pci-e контроллер впихнуть, но сата3 я же никак не высру, верно, там же еще наврное сата2, да и пси-е там же второй версии? Короче подход я думаю вы уловили.
Может есть еще какая-нибудь дешевая платформа, чтоб прям дешево вышло и можно было всякой хуйни в нее насувать?
Я вообще на одноплатнике думаю делать, т.к. арм энергоэффективнее, а значит не придётся платить золотые горы за электричество.
У меня сидбокс с десятком винтов на i5 2500k больше 70 ватт не ест.
Одноплатники дрочь, миллион раз от такой идеи отказывался.
Интерфейсов нихуя нет, а то что есть работает как говно.
Плюс всякие приколюхи до них доходят поздно, т.к. все крутое разрабатывается и компилируется в первую очередь под х86.
Не проще все это по разным железкам разнести? Хотя бы вафлю и свитч.
Сата3 можно попробовать высрать через PCI-E
На авито за 16 тыщ лежит хпе пролиант ген9 с 1225v5, 2 гигабитными портами и 4 дисками по 500гб. По-моему отличное вложение.
>lvm
>ext4
>аппаратный рейд.
Говноеды на марше. Впрочем, чем бы дитя на локалхосте не баловалось, лишь бы в прод не тянуло.
Не у видел в комплекте ИБП. Без него все ваши анальные пляски с рейдами, хфс, зфс и прочиим бтрфс - просто выстрел в ногу.
У меня домашний нас много отлючений электроэнергии пережил. Самое страшное, что было это 3 минуты ресилвера.
Если это то, чем занимается старуха на фото, почему ей ещё перцовкой в лицо пару раз не брызнули?
Причинение по неосторожности
Очередной клоун который кукарекает про аппаратный рейд не изучив матчасть?
Хоть бы с локалхостом и продом не позорился
Проще - дрочь.
Нужно поднять там программный рейд 5 на трёх дисках, NFSv3 для одного клиента с гарантированной скоростью 500мбит и smb или ftp для загрузки контента с низким приоритетом.
Больше не нужно вообще ничего. Главное штабильность.
На какой сборочке это лучше реализовать? Или накатить голый дебиан/центось?
> NFSv3 для одного клиента с гарантированной скоростью 500мбит
Ого. Гарантированная скорость.
Оператива там в первую очередь для массивов на zfs.
С чего вдруг?
ИБП не завезли?
Софтовые рейды вполне себе не плохо переживают скачки напряжения.
Что зфс, что бтрфс. Единственное, что бтрфс потратит больше времени на ресильвер.
Двач-помогач, спаси!! Есть один NAS из кучи старых винтов на 6TiB под управлением NAS4Free. Кончилось место и я напрягши булки, купил пару винтов на 8TiB, корпус с салазками, m-ITX мамку, собрал еще один под управлением XigmaNAS (тот же NAS4Free). Всё работает, всё охуенно, но! Когда втыкаю копирование со старого на новый, такое ощущение, что файлы копируются через вай-фай ноута со скоростью 3Мб/сек. Как, блядь, заставить его копироваться с наса н нас по гигабитной сетке?
Вопрос снят. Снес к хуям XigmaNAS и поставил Windows Server. Подключаюсь по RDP и копирую прямо в папки со скоростью 100мб/сек.
У меня мелкий вопрос. Несовсем по нас, но близко.
При перетаскивании файлов между папок на FTP -сервере в рамках одного физического харда и одной домашней директории скорость упирается в ширину сети (А она wifi).
Samba глючное говно, которое даже не заработало в очередной раз почему-то, хотя сто раз настраивал ранее. Вебдав вообще наркомания.
Что можно попроще придумать, чтоб по вафле расшарить папку для смартфонов, телика и ПК из интернетов на ноутбуке под виндой (он работает роутером, точкой доступа, торентокачалкой и проч)?
Разбираться с настройкой облака под линукс некогда - это потом и на нормальном железе в виде htpc будет делаться.
Надо здесь, сейчас и побыстрее.
Мамку твою уже вызвал
Отговорите, в чем подводные. Проц 4х ядерный 1.5 ггц, должно хватить за глаза + хорошая сетевая подсистема из коробки.
Никаких, это лучший вариант.
>въебу юсб-хаб, на него 4 диска через переходники
Чота вскрикнул.
ПС. Как думаете, такая няша потянет домашнюю файлопомойку? Торренты, там, подкачивать по ночам, варез всякий в зашифрованном виде хранить?
Порватка, хуле ты делаешь в треде, где взрослые, обеспеченные дядьки, собирают себе NASы? Иди засунь свою ардуину себе в очко!
Никогда не являлся поклонником Путина, но как я нагляделся на этих насральных, собчачек, фемок, лгбт и прочих хохлов - по мне уж лучше Путин - это гарант нормальности, по крайней мере. Не в гомосяцком же мире жить. Вообще считаю за пропаганду украины реальные сроки надо давать, вплоть до расстрела
Подводная в том, что тебе надо понимать как работает usb, чтобы выбрать переходник.
А это достаточно сложная тема. В твоем случае может быть аж 3 режима того, как контроллер диска общается с ядром компа. И там везде будет разная инкапсуляция разных протоколов.
Достаточно много писать, я попробую сразу к сути. https://en.wikipedia.org/wiki/USB_Attached_SCSI
Твой переходник должен это поддерживать. Нормальные переходники будут стоить от 1500 рублей. Я полагаю, что даже больше.
Если тебе понадобится больше дисков, то дешевле будет комп с контроллером, чем схема на usb.
Ну и раньше малинка в usb и сеть одновременно плохо могла, может сейчас это уже не так.
Ну такое, вроде как этот uas на 20% процентов ускоряет и складывается впечатление, что в основном для линейных операция.
Даже если и 20%, то хрен с ним, возьму дешман с алика, а скорость все-равно в эзернет упрется.
И да, эти потери на протоколах просто, легко и эффективно нивелируется тупым наращиванием мощностей (тупа дисков больше использовать).
На винде сидишь потому что везде systemd?
кто-нибудь юзал bcachefs ?
думаю ради эксперимента собрать из исходников. Он же в DKMS, так что должно быть норм
Схема дисков такая:
1. 1Тб ССД XFS с ОС и программами/контейнерами
2. 18Тб х2 ХДД BTRFS RAID1 с данными
3. 8Тб ХДД с торрентами
Я хочу, чтобы абсолютно все диски блокировались при выключении.
Желательно, чтобы система требовала 1 пароль, а все диски второй.
Как это правильно реализовать?
LUKS + LUKS/BTRFS?
Пиздос, да вы там реально что-ли ЦОДы дома собираете?
> 18 териков дома
Так это не так много, если аниме в БД-ремуксах хранить, то быстро такое пространство бесследно улетит.
От 4 до 10 лет строгого режима
Видео не сжимаются же. Только перекодировка какими-нибудь энкодерами вроде x264, x265, libvpx, aomenc.
Можно 250 блюриков записать
Поделюсь опытом с опом хуем.
Купил 6 дисков по 8Тб, а диски эти оказались SMR и бтрфсу становилось очень хуево после скачивания 500Гб торенов.
В итоге пришёл к мегасистеме dmraid по 2 диска в рейд1 и три в 0, кароч рейд10 типа, а вместо файлухи лучше всего оказалась f2fs проблем с ней почти нет на smr hdd.(мои диски поддерживают trim)
В качестве хостсистемы центось8 стрим, на ней ничего кроме libvirt,торены и остальные говна в виртуалках, всякая докерпараша в одной виртуалке.
Виртуалки в основном на альпине, но есть и дебиансид и шиндe.
В итоге даволен как слон, зверек работает как часы, ув. Форумчане завидуют.
>бтрфсу
Необучаемый гуманоид использует систему написанную флюидными трансгендерами для инопланетян.
>докер
>в виртуалке
Зачем?
>диски
Спасибо за опыт, я убедился, что взял CMR, так что проблем с BTRFS не будет.
>Зачем докер в виртуалке?
Удобнее делать снапшоты/бекапы если железо своё. Если берешь виртуалки у провайдера - экономия ресурсов аля пять серваков на одной тачке
>Это на уровне ФС, ведь
У него f2fs на гипере и ext4 на виртуалках
>Да и любой докер это уже снапшот.
Если бэкапить волюмы и образы. В случае чего - их все ручками поднимать, очень хорошо, если есть скрипты для поднятия каждого контейнера или в докерфайле всё задокументированно или вообще всё на docker-compose. В целом, как вариант, но проще virsh'ом снэпшоты делать
>образы
Сам докер контейнер иммютэбл.
При перезапуске будет стартовое состояние.
А вообще, kubernetes.
За кубер не шарю, но тут речь идёт не о перезапуске контейнеров. Если у автора поста похерится диск с докером в raid0, получится только создавать контейнеры по новой. Тут уже сохраняться только данные из образа и волюмов, иммютабельность не поможет.
Может и не надо, но у автора он и стоит. Скорее всего для торрента, ну и в таком случае - докер в относительной безопасности. Не застрахован разве что землетрясения или скачка напряжения
Мне он пока больше всего нравится. Винда сразу увидела его в шарах (на виртуалке), диски подключаются и всё такое.
Сразу говорю, конфигурация дисков ебанутая - у меня стопка дисков в NTFS, и конвертить их в другие ФС долго и я не вижу смысла. Отдельные диски проще подключать к обычным ПК и всё такое. Но это не для важной информации, а для торрент шар. Для важных файлов хотел бы нахлобучить BtrFS как умеющую в нормальное расширение на новые диски.
Вот кстати какой торрент клиент на Linux адекватно тянет тысячи раздач (у меня сейчас в uTorrent больше 1,5к раздач), имеет веб интерфейс с возможностью выбирать путь и конкретные файлы для каждой раздачи, желательно при этом сохраняя ошмётки невыбранных файлов в один файлик в корне раздачи, а не засирая всё призраками.
Rutorrent
Заебись потянет.
> Для выполнения своего кода в системе атакующие эксплуатируют особенность реализации XML-RPC в rTorrent, в которой не отключён метод "execute", позволяющий выполнить любой shell-код в системе.
Меня вообще удивляет, о чём думают программисты, которые встраивают такие функции в форматы данных. Такое ощущение, что 90% подобных "уязвимостей" были допущены просто потому, что какой-то кретин решил, что заебись же будет, если из языка для разметки документов можно будет вызвать любую программу в системе.
Да не, большинство программистов хуя ложили на эту вашу безопасность, только если не работают в военке. Чуть что - ай ой zero day, щас пофиксим всё буит
Да не, самый пиздец это браузеры, которые разрешают вот эти все DNS rebinding и обращение к локальным адресам со страницы, загруженной из интернета.
Это копия, сохраненная 5 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.