Планирую делать полноценный «дэйта-сэнтр» в домашних условиях.
Далее будут приведены цели и ПО, которое планирую использовать.
Скажи, если для чего есть лучшие альтернативы.
ОС: RHEL
ФС: BTRFS (RAID1 -> RAID10)
стриминг видео с декодированием на сервере: jellyfin
файлопомойка с синхронизацией телефона: nextcloud
стриминг аудио с кешированием на устройстве: airsonic
VPN: wireguard
торренты с автораспределегием по директориям: rtorrent
веб сайты: пока не знаю, потом прикручу контейнеры
* контейнеры: Docker
Все норм?
> торрент
Почему не легковесный Transmission?
> OS
Я бы посоветовал какой-нибудь FreeNAS. Местные аноны в этом плане лучше подскажут, но RHEL явно не твой выбор
Да и вообще ниже есть целый тред по насам, спросил бы там
>rtorrent
Отличную машинку для майнинга собрал.
https://www.opennet.ru/opennews/art.shtml?num=48177
> Атака производится когда пользователь открывает в браузере подконтрольные злоумышленнику страницы на системе в которой также выполняется rTorrent.
Не актуально для меня.
Ну и если знаешь другой клиент, который следит за директориями и автоматически качает по нужным путям, могу перейти на него.
> ОС: RHEL
лалка ебучая RHEL это засохшее говно с systemd и дилдами
Это ебучее говно на питоне с постоянными проблемами при обновлении и самым медленным пакетным менеджером?
Не говоря уже о том, что OpenRC это чуть ли не самый медленный система инитов.
Спасибо за рекомендацию, но нет.
Лучше уж NixOS обмазаться.
Тоже верно.
Теперь либо БСД, на который не все портировано пока либо СистемД.
>>2904995
Пакеты начали сегфолтится, очень многое стало значительно дольше обновляться.
Новый хэндбук просто крупная Параша по сравнению даже со старыми доками.
Форум убрали.
Глав. Девы с самомнением уровня разработчиков ГНОМ, хотя по сравнению с экстремом не сделали и 10 части все вместе.
Единственный плюс за последний год- 64-битный вайн.
>NAS
>RAID10
>торренты
Паршивая идея.
>>2904825
>Ну тогда тебе нужно ECC Ram
Не нужно. "Scrub of death" - полумифическая хрень, наблюдать которую у тебя шансов не больше, чем восстановить случайную строку по ее sha256-хэшу с одной попытки.
>>2904826
>и хотя бы raidz2
Для дисков <= 4ТБ не имеет смысла.
>BTRFS
>RHEL
Слабоумие и отвага.
>>2905016
>но заводить ZFS на лине это такое себе.
Оно прекрасно работает.
>Почему?
Потому что будешь скрежетать головамии всех дисков в массиве 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 попробовал, но он ещё даже не в ядре.
У ZFS не БСД.
Поэтому там и проблемы.
OpenZFS лицензируется под CDDL (Common Development and Distribution License)
>>2905492
>>никогда не добавят в ядро
Разщницы в работе и коде нет вообще, нули и единички те-же, тебе ли не похуй?
Ну пересобери ведро сам с вшитым модулем.
Аутисты блядь.
>Для дисков <= 4ТБ не имеет смысла
Почему, и как вообще parity связано с размером диска?
А насчет ECC, ты думаешь он просто так стоит в любом сервере? И не забывай, что при async записи ZFS кладет все в рам а потом скидывает на диск, там то и сожет случиться косяк, ну или во время resilver. Ошибки РАМа это частое явление, прост без ECC ты о них не знаешь.
https://serverfault.com/questions/26483/statistics-on-ram-malfunction
Ты как-то совсем уже в странности двинулся.
Перестань дерейлить тред.
> 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.
Ну да, хороший чек, ниче не скажешь, лол.
>>2906515
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!
>нормально работает на прошлых ядрах яскозал
>это значит что оно стабильное в релизе
Недостаточно стабильное для БРБРФС
Ставь TrueNAS + ZFS. В bhyve поднимешь линокс и бушь гонять там докер.
> Нам на аппле брбрфс нинужон, есть нормально работающая APFS
Да как скажешь
>пикрил
Чет сильверстоун в край обленились, поменяли морду от SG 13 и воткнули шасси - насик готов!
Да просто так.
В btrfs есть копи он врайт (как в варе; сразу вспоминается - если хочешь иметь проблемы с созданием снэпшота, выбирай хв, если с удалением - вару) и б-деревья.
Ни первое, ни второе не будет нужно на нас.
Первое нужно там, где есть требования по ревизиям снимков данных и если это меньше 300тб, то это скорее решается бэкапом, а второе нужно - где данных много.
Если уж хочется чего-то не дефолтного, то и правда zfs.
>>2907794
Если opennas, или truenas могут в докер, то самое разумное, имхо.
Я в итоге на другом корпусе остановился.
У сильверстоуна (и большинства альтернатив) кулер далеко от дисков расположен и люди жалуются на температуры.
В итоге жду U-NAS NSC-810 в продаже.
>>2918316
“Стабильность”, снепшоты и нативная поддержка нескольких уровней RAID.
А, ещё драйвер для виндоус. Некоторые даже винду с него запускают в виртуальной.
>кулер далеко от дисков расположен
Жёсткие диски не надо охлаждать. Особенно в насе, где они простаивают 95% времени.
>По твоему же пикрилу видно, что в идеале +35+45.
Средний винт без обдува и висит в интервале 30-35. Пикрел мой медиацентр-сидбокс у батареи без какого-либо обдува.
До 50 реально самые запущенные валенки кипятятся.
Мы же тут вроде домашнюю файловую помойку собираем, а не что-то для работы со снепшотами виртуальных машин и/или еще чем-то. Помои можно, и имхо, нужно хранить на mdadm+ext4. Скорость доступа выше чем у ZoL/BTRFS, а что еще нужно неискушенному пользователю?
>без виртуалок
Но с контейнерами.
Лично я беру BTRFS, потому что из коробки максимально просто собрать нужный мне RAID1/10 и может в дедупликацию, расширение массивов и все прочее.
Какой плюс от использования отдельной утилиты (mdadm), если ФС нативно все поддерживает?
Ну и у меня личная неприязнь к EXT4, после того, как у меня умудрились закончиться иноды при нормальном использовании ПК.
Может и имеет смысл.
У меня около 5 лет файловая помойка жила на nfs + mdadm из 4 винтов, бед не знал, даже без упса. Пережила много отключений электроэнергии, рейд так и не развалился.
Так же крутил там minidlna / transmission-daemon / owncloud / strongswan + xl2tpd. Бед не знал.
В прошлом году купил синьку ds920+. ВПН сервер переехал на vyos.
У меня, кстати, тоже не поднимается выше 30 градусов даже при нагрузке.
>>2918350
Может у вас там 5400 стоит на 4Тб?
Я пикрил брать собираюсь.
Ты картинку-то посмотрел?
Всё что касается ФС должно быть масимально дефолтным. Каждый дополнительный слой увеличивает шансы что всё распидораится, что никакие утилиты не помогут. Лично я в хранилищах пришёл к схеме:
1) ext4
2) raid/mdadm дома не нужен, только на продакшн серверах для минимизации простоя
3) lvm нужен только если планируешь склеивать больше одного винта, или добавлять диски
4) бэкапы borgом на другой винт, или на другое хранилище, не забывать чекать здоровье по хрону
5) шифрование в отдельных контейнерах если шибко надо
7) PROFIT
В результате даже если я внезапно потеряю бэкапы, у меня останется куча инструментов по разруливанию ситуации от ддрескью и тестдиска до платной рстудио.
>Что, блядь?
https://www.r-studio.com/ не путать с https://rstudio.com/
Отлично работает с ext4. На резонный вопрос: "на кой это надо, если есть тестдиск" отвечаю.
1) Коллеги не раз говорили, что он больше файлов достаёт.
2) Лично я могу подтвердить, что он работает в несколько раз быстрее.
3) Доступный, его можно поручить любой эникейной обезьяне.
В общем достойный продукт за свои деньги.
>Но с контейнерами.
Пяток контейнеров же. Их конечно очень часто снэпшотить надо. Прям поддержка от фс нужна.
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.
>условия
Вроде по все подхожу, кроме рекомендованной ОС, но это лишь рекомендация.
Сама система менеджмента контейнеров. Она может использовать фичи фс. Но тут, как мне кажется, не тот случай, чтоб этим заморачиваться.
>>2918488
> активно рассматриваю.
> Так для ОС и всех контейнеров там ССД на терабайт
Ясно.
> а массивы примантированны
Т.е. в сухом остатке имеем именно:
"Нативная работа с многими дисками и нужные уровни RAID."
Т.е. к контейнеру ты будешь монтировать вольюм? Или через bind?
Хорошая, годная статья для выбора софт рейда.
Хорошая, годная статья для выбора софт рейда.
Я бы хотел биндить, но поскольку мне нужно несколько контейнеров к одному пулу дисков, думаю, придётся вольюмами.
Пока эта система только для меня, но надо ещё подумать, как потом распределять доступ.
Возможно, у подмана с этим лучше?
>>2918733
Повторю, что говорил выше: «если нужна только файлопомойка, то синолоджи— отличный вариант».
Если нужно хоть что-то ещё, то это лютый проглотим. Там даже с FFMPEG трудности.
Я уж не говорю про БТРФС на ядре времён палеозоя.
FreeNAS + zfs + openvpn. Вот настоящий топ.
Тебе википедии не хватает?
Позволяет блочное устройство подключать по сети.
Тип не папочку с файлами а диск, как диск, который ты можешь форматровать во что хош и установить туда ОС.
Юзкейсы - ну например виртуализация и бесдисковые станции. А так же всевозможные SANы.
SAN это когда у тебя диски в одной комнате управляемые централизованно, а сервера в другой.
>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.
Ну т.е. ладно, забыли про контейнеры. Для них бртфс тебе не нужна.
У тебя есть 1 диск под систему, 4 под рэйд 10 с семейными фото, 1 под торренты. Диски - это около 60к рублей, еще 20 - под считалку. Т.е. 80к под нас с семейными фото, я ничего не упустил?
> файлопомойка с синхронизацией телефона: nextcloud
Эта хуйня заприватит шареную папку и доступ к ней будет только через него. Если ты хочешь в те папки ходить свободно, расшарь по самбе и подключи как внешнее хранилище.
>блочные устройства
Нет.
SSD: XFS -> ОС, контейнеры, все прочее
HDD: BTRFS RAID1/10 -> все данные
У докера есть драйверы для нативной работы с BTRFS.
Сейчас почитал про вольюмы побольше, от них действительно будут некоторые неудобства.
Хотя, если РЭЙД сделан средствами самой ФС (как в моем случае), то никаких проблем быть особо не должно.
Тогда смотрю, можно ли нескольким контейнерам без проблем забиндить диски.
А сколько всего дисков? Штук. Мне правда интересно как насы используют.
И сколько лет это все у тебя работает?
У меня есть опосредованный опыт с brtfs, про частные облака, там выделяли специальную команду из нескольких человек под это. Примерно как сторадж команда, но их специфика была - сбор перформанс метрик. Дитрейс с рестапи, если образно говорить. Т.е. это скорей сириуз бизнес.
И есть прямой опыт с ZFS с прошлой работы, однако как-бы не совсем опыт. У меня никогда ничего не случалось. Но там и данные не клиентов лежали, а внутренние. Единственный опыт - следить за тем, чтобы кондиционер не забывали включать летом, а то можно в понедельник нескольких дисков недосчитаться.
Я оп пост читаю так - есть примерно 4 типа данных.
И надо выбрать политику хранения. Подойдёт ли brtfs c рейд 10?
>>2918958
Сначала я подумал, что brtfs тебе нужно для контейнеров. И я позволил себе усомниться, что для пятка контейнеров это принесет что-то ощутимое.
Потом оказалось, что не для этого, а просто для рэйда средствами фс.
Дальше вывод такой - для 4 типов данных, политика, которая просто подазумевает какой-то один тип рейда, это странное решение. Так можно сделать, вопросов нет. Если ты хочешь на все данные накатить такую-то политику и brtfs позволяет эту политику реализовать - гоу он. Вопрос только в том почему ты выбрал такую политику. А этого как раз в оп посте нет.
>>2918967
Да.
Под виндоус - rapid storage technology.
У эппл - Fusion.
Linux - 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 для твоих данных - странно.
>тогда бинд
Хорошо, спасибо тебе.
>торренты
Их как раз теперь планирую на отдельный диск вне рейда, так как анон выше сказал, что пихать их в основной рейд— крайне тупая идея.
То есть качается через 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 подходы по снэпшотам, чтобы четче понимать про какую дельту ты говоришь.
Угу.
Я читнул про дедуп в этой битриэфэс.
Он там реально нужен, чтоб между снэпшотами дедуплцировать - 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
}
Объявили. И всё. Нигде больше не используем. Поэтому я не понимаю что ты пытаешься донести своим:
> Докер при копировании слепка указывает, что копирование с дедупликацей.
И с радостью бы узнал, если чего-то не знаю.
> Под слепками я понимал слои юнионфс.
Так ты не про родной btrfs дедуп говоришь? Ну за такими скачками с одного на другое мне сложно угнаться.
Я смотрю на вводную треда - btrfs позволяет дедуп. Ни о каком докере речи пока нет.
Дальше я смотрю что именно он позволяет в этом плане.
Есть два режима работы. Один - онлайн, и как по мне - он сырой, второй оффлайн. И его действительно можно использовать. И использовать его можно эффективно, если есть много снэпшотов фс.
Дальше - если докер сконфигурировать определённым образом, он может задействовать btrfs снэпшоты. Я такого никогда не делал, судя по описанию - делать этого не советуют.
Но если сделать, то такой метод действительно позволит экономить на дедупе.
Однако в треде не предполагают, что контейнеры лежат на btrfs.
А потом появляешься ты и говоришь про совершенно другой "дедуп", который и не дедуп вовсе, а нативная докер абстракция над сторадж драйвером. И докер знать не знает что за этим стоит.
Приведет ли этот механизм к тому-же, что и родной офф-лайн btrfs дедуп? Да, но мне кажется, что в меньшей степени. Утилита для офф-лайн дедупа соберёт все чексуммы всех датаблоков. Она ничего не знает о наследовании слоёв докера.
> Дедуплицировать персистентные данные дешево никак не выйдет.
Тут спору нет.
Какое железо?
Ебать. У меня аж сердечко закололо.
Подумываю как бы дешево собраться, взять корудуба на авито или зион с али какой-нибудь, а ты мне такое сбрасывешь.
Ебать.
Дайте линк на НАС-тред.
Вы просто не знаете, какая йоба у меня дома стоит.
Нет никакого NAS треда. Для хранения данных достаточно даже роутера с внешним диском, далее начинаются хотелки, что для некоторых, ещё бы неплохо иметь видеокарту в сервере, например рендерить видео на серваке в подвале, чтобы не шумело в комнате.
>плюс ещё немного
>да
>БД рипы/ремуксы/диски с транскодированием на сервере.
Все мечтаю, что начнут продавать ДРМ-фри видеофайлы без региональных ограничений. Я даже фильмы покупать честно начну.
>gh.de
Просто потрясающий сайт с кучей параметров на любой вкус и ценами в Германии.
>>2919105
Ты понял мою хотелку превосходно.
>почему1/10
Стопроцентный реданданси просто на всякий случай и максимальная скорость.
А BTRFS позволяет это нативно реализовать и менеджить.
>Массив
Я это как заменитель RAID использую, то есть «дисковый массив».
Да что ты знаешь о хранении данных, сынок? Нам похуй на твои поделки из говна и палок.
Отбери у тебя говнороутер от китайского ноунейма с внешним диском и что от тебя останется? Ты сможешь собрать рейд за zfs имея при себе только калькулятор? Ты сможешь сохранить данные там где им не место?
Мы будем собирать НАСы из самых дорогих комплектующих ИСКЛЮЧИТЕЛЬНО для того чтобы качать говносериалы, музыку в 64 кб\с и хранить фотографии того как дядя Петя уморительно нахуярился на своем юбилее. Ты понимаешь? Нам похуй. Средства не важны, цели не важны, важен сам путь.
> Ты сможешь собрать рейд за zfs имея при себе только калькулятор?
Какая йоба у тебя дома стоит?
Нужно намутить сервер, с 2я эзернет портами гигабитными и вайфай, дабы был роутером, поднять джит и некстклауд, файлопомойку, по классике торрент, прокси/впн и еще что-то.
Бюджет 5-6к на все про все, без учета дисков.
Присматриваюсь к авито-говну на лга771 сокете, кор2квад/зион, но я вот хуй знает как выйдет по интерфейсам. Хуй знает как это все прикрутить, вайфай/эзернет можно через usb pci-e контроллер впихнуть, но сата3 я же никак не высру, верно, там же еще наврное сата2, да и пси-е там же второй версии? Короче подход я думаю вы уловили.
Может есть еще какая-нибудь дешевая платформа, чтоб прям дешево вышло и можно было всякой хуйни в нее насувать?
Одноплатники дрочь, миллион раз от такой идеи отказывался.
Интерфейсов нихуя нет, а то что есть работает как говно.
Плюс всякие приколюхи до них доходят поздно, т.к. все крутое разрабатывается и компилируется в первую очередь под х86.
Будем тихо по ночам спускаться на твой этаж и вырубать пробки
Нужно поднять там программный рейд 5 на трёх дисках, NFSv3 для одного клиента с гарантированной скоростью 500мбит и smb или ftp для загрузки контента с низким приоритетом.
Больше не нужно вообще ничего. Главное штабильность.
На какой сборочке это лучше реализовать? Или накатить голый дебиан/центось?
При первом скачке 220 весь твой бтрфс полетит к хуям.
Двач-помогач, спаси!! Есть один NAS из кучи старых винтов на 6TiB под управлением NAS4Free. Кончилось место и я напрягши булки, купил пару винтов на 8TiB, корпус с салазками, m-ITX мамку, собрал еще один под управлением XigmaNAS (тот же NAS4Free). Всё работает, всё охуенно, но! Когда втыкаю копирование со старого на новый, такое ощущение, что файлы копируются через вай-фай ноута со скоростью 3Мб/сек. Как, блядь, заставить его копироваться с наса н нас по гигабитной сетке?
У меня мелкий вопрос. Несовсем по нас, но близко.
При перетаскивании файлов между папок на FTP -сервере в рамках одного физического харда и одной домашней директории скорость упирается в ширину сети (А она wifi).
Samba глючное говно, которое даже не заработало в очередной раз почему-то, хотя сто раз настраивал ранее. Вебдав вообще наркомания.
Что можно попроще придумать, чтоб по вафле расшарить папку для смартфонов, телика и ПК из интернетов на ноутбуке под виндой (он работает роутером, точкой доступа, торентокачалкой и проч)?
Разбираться с настройкой облака под линукс некогда - это потом и на нормальном железе в виде htpc будет делаться.
Надо здесь, сейчас и побыстрее.
>Хохол что ли?
??
Никогда не являлся поклонником Путина, но как я нагляделся на этих насральных, собчачек, фемок, лгбт и прочих хохлов - по мне уж лучше Путин - это гарант нормальности, по крайней мере. Не в гомосяцком же мире жить. Вообще считаю за пропаганду украины реальные сроки надо давать, вплоть до расстрела
Подводная в том, что тебе надо понимать как работает usb, чтобы выбрать переходник.
А это достаточно сложная тема. В твоем случае может быть аж 3 режима того, как контроллер диска общается с ядром компа. И там везде будет разная инкапсуляция разных протоколов.
Достаточно много писать, я попробую сразу к сути. https://en.wikipedia.org/wiki/USB_Attached_SCSI
Твой переходник должен это поддерживать. Нормальные переходники будут стоить от 1500 рублей. Я полагаю, что даже больше.
Если тебе понадобится больше дисков, то дешевле будет комп с контроллером, чем схема на usb.
Ну и раньше малинка в usb и сеть одновременно плохо могла, может сейчас это уже не так.
Ну такое, вроде как этот uas на 20% процентов ускоряет и складывается впечатление, что в основном для линейных операция.
Даже если и 20%, то хрен с ним, возьму дешман с алика, а скорость все-равно в эзернет упрется.
И да, эти потери на протоколах просто, легко и эффективно нивелируется тупым наращиванием мощностей (тупа дисков больше использовать).
кто-нибудь юзал bcachefs ?
Схема дисков такая:
1. 1Тб ССД XFS с ОС и программами/контейнерами
2. 18Тб х2 ХДД BTRFS RAID1 с данными
3. 8Тб ХДД с торрентами
Я хочу, чтобы абсолютно все диски блокировались при выключении.
Желательно, чтобы система требовала 1 пароль, а все диски второй.
Как это правильно реализовать?
LUKS + LUKS/BTRFS?
AV1!
Только пока нет процессоров с аппаратной поддержкой, если не ошибаюсь.
>>2934076
Пока ничего.
Сейчас пришли диски, через месяц-полтора ожидаю полную сборку.
Поделюсь опытом с опом хуем.
Купил 6 дисков по 8Тб, а диски эти оказались SMR и бтрфсу становилось очень хуево после скачивания 500Гб торенов.
В итоге пришёл к мегасистеме dmraid по 2 диска в рейд1 и три в 0, кароч рейд10 типа, а вместо файлухи лучше всего оказалась f2fs проблем с ней почти нет на smr hdd.(мои диски поддерживают trim)
В качестве хостсистемы центось8 стрим, на ней ничего кроме libvirt,торены и остальные говна в виртуалках, всякая докерпараша в одной виртуалке.
Виртуалки в основном на альпине, но есть и дебиансид и шиндe.
В итоге даволен как слон, зверек работает как часы, ув. Форумчане завидуют.
>докер
>в виртуалке
Зачем?
>диски
Спасибо за опыт, я убедился, что взял CMR, так что проблем с BTRFS не будет.
>Это на уровне ФС, ведь
У него f2fs на гипере и ext4 на виртуалках
>Да и любой докер это уже снапшот.
Если бэкапить волюмы и образы. В случае чего - их все ручками поднимать, очень хорошо, если есть скрипты для поднятия каждого контейнера или в докерфайле всё задокументированно или вообще всё на docker-compose. В целом, как вариант, но проще virsh'ом снэпшоты делать
За кубер не шарю, но тут речь идёт не о перезапуске контейнеров. Если у автора поста похерится диск с докером в raid0, получится только создавать контейнеры по новой. Тут уже сохраняться только данные из образа и волюмов, иммютабельность не поможет.
Мне он пока больше всего нравится. Винда сразу увидела его в шарах (на виртуалке), диски подключаются и всё такое.
Сразу говорю, конфигурация дисков ебанутая - у меня стопка дисков в NTFS, и конвертить их в другие ФС долго и я не вижу смысла. Отдельные диски проще подключать к обычным ПК и всё такое. Но это не для важной информации, а для торрент шар. Для важных файлов хотел бы нахлобучить BtrFS как умеющую в нормальное расширение на новые диски.
Вот кстати какой торрент клиент на Linux адекватно тянет тысячи раздач (у меня сейчас в uTorrent больше 1,5к раздач), имеет веб интерфейс с возможностью выбирать путь и конкретные файлы для каждой раздачи, желательно при этом сохраняя ошмётки невыбранных файлов в один файлик в корне раздачи, а не засирая всё призраками.
> Для выполнения своего кода в системе атакующие эксплуатируют особенность реализации XML-RPC в rTorrent, в которой не отключён метод "execute", позволяющий выполнить любой shell-код в системе.
Меня вообще удивляет, о чём думают программисты, которые встраивают такие функции в форматы данных. Такое ощущение, что 90% подобных "уязвимостей" были допущены просто потому, что какой-то кретин решил, что заебись же будет, если из языка для разметки документов можно будет вызвать любую программу в системе.