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: 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 как раз вызывает интерес к оной файловой системе. Поскольку там немало бэкапов, и порой файлы в них переезжают, эта функциональность представляется нелишней. Расслабиться на тему "ну и что, что сотню гигабайт переложили и потрогали, к завтрему перелинкуется" было бы приятно.
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 адрес и следующие за деньги - идут мимо моих денег. Мне проще затащить свой сервер к кому-нибудь, где его можно поставить в угол и платить аренду пивом-коньяком ;)
