Re: btrfs?
Никак, или смирится что btrfs это альфа софт и пересесть на другую или выполнять каждый раз. У меня такое проявлялось после использования btrfs около месяца. А после она начинает потихотьку сыпаться. On 02/11/2018 02.07, Alexander Wiedergold wrote: привет, может кто помочь? как это быстро исправить? или нужно всегда выполнять: btrfs check --init-csum-tree /dev/sda3 checksum verify failed on 917602304 found 1C912D88 wanted DEC42EC0 checksum verify failed on 917602304 found 1C912D88 wanted DEC42EC0 спосибо Am 01.11.2018 um 19:50 schrieb Igor Savluk: Здрааасьте, проснулся. btrfs давно закопали даже ее создатели (redhat). Если интересны пруфы гугли по Red Hat to Drop Support for Btrfs Это уже давно обсуждали, и даже вроде тут ветка была обмусоливали почему и как это. On 01/11/2018 20.54, Artem Chuprina wrote: Хмутро. Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами? А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее временной мерой, и уже пора переходить на btrfs, а в дебиановской вики перечислено такое количество тараканов... Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу заворачивали". Типа, эта функция есть, но чревата потерей данных, так что лучше не использовать. Компрессию лучше не использовать. dpkg (если делать рут на btrfs) страшно тормозит, и чинить это никто не будет. И все это касается в том числе и свежих ядер, в смысле, более свежих, чем в stable. Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых, нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той машинке быстрый SATA-выход один. Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs, не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо zfs (и btrfs) динамически распределяют под них место, но что-то тоже практического применения не сложилось. А вот косой взгляд на инструменты out-of-band deduplication для btrfs как раз вызывает интерес к оной файловой системе. Поскольку там немало бэкапов, и порой файлы в них переезжают, эта функциональность представляется нелишней. Расслабиться на тему "ну и что, что сотню гигабайт переложили и потрогали, к завтрему перелинкуется" было бы приятно.
Re: btrfs?
привет, может кто помочь? как это быстро исправить? или нужно всегда выполнять: btrfs check --init-csum-tree /dev/sda3 checksum verify failed on 917602304 found 1C912D88 wanted DEC42EC0 checksum verify failed on 917602304 found 1C912D88 wanted DEC42EC0 спосибо Am 01.11.2018 um 19:50 schrieb Igor Savluk: Здрааасьте, проснулся. btrfs давно закопали даже ее создатели (redhat). Если интересны пруфы гугли по Red Hat to Drop Support for Btrfs Это уже давно обсуждали, и даже вроде тут ветка была обмусоливали почему и как это. On 01/11/2018 20.54, Artem Chuprina wrote: Хмутро. Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами? А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее временной мерой, и уже пора переходить на btrfs, а в дебиановской вики перечислено такое количество тараканов... Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу заворачивали". Типа, эта функция есть, но чревата потерей данных, так что лучше не использовать. Компрессию лучше не использовать. dpkg (если делать рут на btrfs) страшно тормозит, и чинить это никто не будет. И все это касается в том числе и свежих ядер, в смысле, более свежих, чем в stable. Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых, нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той машинке быстрый SATA-выход один. Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs, не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо zfs (и btrfs) динамически распределяют под них место, но что-то тоже практического применения не сложилось. А вот косой взгляд на инструменты out-of-band deduplication для btrfs как раз вызывает интерес к оной файловой системе. Поскольку там немало бэкапов, и порой файлы в них переезжают, эта функциональность представляется нелишней. Расслабиться на тему "ну и что, что сотню гигабайт переложили и потрогали, к завтрему перелинкуется" было бы приятно.
Re: Tidy validation failed
Чт 01 ноя 2018 @ 16:39 Debian Webmaster : > *** /srv/www.debian.org/www/events/index.ru.html > line 55 column 40 - Warning: inserting implicit > line 55 column 40 - Warning: trimming empty Исправил.
Re: btrfs?
On 11/1/18 8:54 PM, Artem Chuprina wrote: > Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами? Непосредственно сейчас не скажу, но год-полтора назад, когда я несколько неупорядоченно уползал с extN, на одной машине я экспериментировал и с btrfs. Поломалась примерно через полтора месяца после установки. Всех подробностей не помню, но точно помню как небольшое количество неудаляемых файлов и директорий (rm/rmdir вылетал с ошибкой и маловразумительной руганью в логи), так и небольшое количество файлов с перепутанным содержимым, например, текстовый .tar.gz, который я создать именно в таком виде навряд ли мог. Это был рабочий ноут со среднепрограммерским паттерном использования, из особенностей использовались дедупликация, cp --reflink и сенд бэкапов на соседнюю машину. Какое именно действие поломало, установить не удалось. Снес и больше не пробовал.
Re: btrfs?
Здрааасьте, проснулся. btrfs давно закопали даже ее создатели (redhat). Если интересны пруфы гугли по Red Hat to Drop Support for Btrfs Это уже давно обсуждали, и даже вроде тут ветка была обмусоливали почему и как это. On 01/11/2018 20.54, Artem Chuprina wrote: Хмутро. Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами? А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее временной мерой, и уже пора переходить на btrfs, а в дебиановской вики перечислено такое количество тараканов... Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу заворачивали". Типа, эта функция есть, но чревата потерей данных, так что лучше не использовать. Компрессию лучше не использовать. dpkg (если делать рут на btrfs) страшно тормозит, и чинить это никто не будет. И все это касается в том числе и свежих ядер, в смысле, более свежих, чем в stable. Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых, нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той машинке быстрый SATA-выход один. Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs, не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо zfs (и btrfs) динамически распределяют под них место, но что-то тоже практического применения не сложилось. А вот косой взгляд на инструменты out-of-band deduplication для btrfs как раз вызывает интерес к оной файловой системе. Поскольку там немало бэкапов, и порой файлы в них переезжают, эта функциональность представляется нелишней. Расслабиться на тему "ну и что, что сотню гигабайт переложили и потрогали, к завтрему перелинкуется" было бы приятно.
btrfs?
Хмутро. Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами? А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее временной мерой, и уже пора переходить на btrfs, а в дебиановской вики перечислено такое количество тараканов... Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу заворачивали". Типа, эта функция есть, но чревата потерей данных, так что лучше не использовать. Компрессию лучше не использовать. dpkg (если делать рут на btrfs) страшно тормозит, и чинить это никто не будет. И все это касается в том числе и свежих ядер, в смысле, более свежих, чем в stable. Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых, нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той машинке быстрый SATA-выход один. Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs, не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо zfs (и btrfs) динамически распределяют под них место, но что-то тоже практического применения не сложилось. А вот косой взгляд на инструменты out-of-band deduplication для btrfs как раз вызывает интерес к оной файловой системе. Поскольку там немало бэкапов, и порой файлы в них переезжают, эта функциональность представляется нелишней. Расслабиться на тему "ну и что, что сотню гигабайт переложили и потрогали, к завтрему перелинкуется" было бы приятно.
Tidy validation failed
*** /srv/www.debian.org/www/events/index.ru.html line 55 column 40 - Warning: inserting implicit line 55 column 40 - Warning: trimming empty -- You received this mail for the language code ru. Please edit webwml/english/devel/website/validation.data if this is not accurate. Please also update webwml/english/devel/website/ with the new coordinator(s) data.
Re: html__ddtp2 предлагает описания для переведённых пакетов?
В Ср, 31/10/2018 в 16:59 +0300, Алексей Шилин пишет: > > Нет, это просто перевод неправильный. В оригинале: "aims to provide > translated > package descriptions". Спасибо за ответ. Я уже сама поняла это, потому что там есть переведённое на русский, а сам пакет ещё не переведён. Надо будет внимательно почитать эту страницу и сверить её с английским текстом.
Re: LXC vs Docker и форматы контейнеров
On Thu, 1 Nov 2018 14:59:23 +0300 "Andrey Jr. Melnikov" wrote: > > Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz > > контейнер был не за доллар в месяц, а за 5, и виртуалка теперь > > примерно за такие же деньги. > Сложный вопрос - за то-же самое хотят по $5-$6, а платить за > виртуалку с la 0.0 за последние 2 года - земноводное душит. Ну значит надо сервисы диверсифицирвоать. Чтобы за их комплект не жалко было $5 отдавать. У меня ж там не только и не столько web, сколько всякие другие вещи - почта (в том числе и с вебмейлом) - джаббер - mumble - CardDAV/CalDAV - Сервер SyncThing, организованного по схеме звезда - Сервер OpenVPN, благодаря которому я могу зайти по ssh на любую из своих машин даже если она за провайдерским NAT. Ну и не только по ssh. Transmission на домашней машине я тоже так порулить могу. Т.е. в основном оно используется для того что обычный современный юзер отдает Гуглю, а я не хочу. Ну и фоточки тоже там хранятся. (кстати, думаю их оттуда унести, по крайней мере полноразмерные. А то что-то места мало осталось). > Мне проще затащить свой сервер к кому-нибудь, где его можно поставить > в угол и платить аренду пивом-коньяком ;) Если продать тот сервер на eBay, то сколько лет можно с полученных денег платить по $5 в месяц? И сколько шансов что сервер за эти годы не сдохнет?
Re: LXC vs Docker и форматы контейнеров
Victor Wagner wrote: > В Thu, 1 Nov 2018 01:59:59 +0300 > "Andrey Jr. Melnikov" пишет: > > Michael Shigorin wrote: > > PS: Вот гляжу я на контейнер за $1: > > ~# uname -a > > Linux ns2 2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 > > x86_64 GNU/Linux > > > > и возникает у меня мысль - а не пора ли свой доллар нести дяде с lxc. > > или с kvm. Т.к. дельцы с openvz забили на апгрейды. Или у них платная > > поддержка кончилась. > Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz > контейнер был не за доллар в месяц, а за 5, и виртуалка теперь > примерно за такие же деньги. Сложный вопрос - за то-же самое хотят по $5-$6, а платить за виртуалку с la 0.0 за последние 2 года - земноводное душит. Да и барыги с идиотскими тарифами где как достижение 1 IPv6 адрес и следующие за деньги - идут мимо моих денег. Мне проще затащить свой сервер к кому-нибудь, где его можно поставить в угол и платить аренду пивом-коньяком ;)
Re: LXC vs Docker и форматы контейнеров
On Wed, 31 Oct 2018 23:20:06 +0300 Michael Shigorin wrote: > On Thu, Oct 11, 2018 at 07:40:19AM +0300, Victor Wagner wrote: > > Итак, что может хотеться получить: > > > > 1. Обеспечить работу недоверенных приложений, возможно > > нескольких взаимодействующих, возможно предъявляющих > > несовместимые требования к операционным системам, в которых > > развернуты. Под эту задачу создавался докер. > > Это дыркер-то? Виктор, ну Вы-то можете различать контейнеры > (которые были ровно ovz/vz) и дырявые кошёлки для удобства > переноски разных кучек всякого (а это то, что может дать lxc > и около)... Да. И я тут описываю именно задачу для которой нужны "дырявые кошелки". Более того, зачастую и они избыточны. Хватило бы даже не chroot, а чуть более строгого разграничения прав на файловую систему по пользователям и группами. А для задач, под которые создавался vz сейчас проще использовать kvm. Да, оверхед от лишнего ядра. Но это дешевле чем бороться с ядрами с версией ниже числа e. > > > При этом надо понимать, что если вы ходите что-то серьезное > > хостить > > ...то сперва стоит посмотреть https://www.cvedetails.com/product/28125 > и характер дырок, потом очень-очень осторожно спросить kir@ А какой смысл? Все равно взломают. Сейчас гораздо выгоднее вкладываться в процедуры своевременного обнаружения, и восстановления после взлома, а не тешить себя иллюзиями невзламываемых систем. --
