btrfs?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

btrfs?

Artem Chuprina-4
Хмутро.

Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее
временной мерой, и уже пора переходить на btrfs, а в дебиановской вики
перечислено такое количество тараканов...

Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу
заворачивали". Типа, эта функция есть, но чревата потерей данных, так
что лучше не использовать. Компрессию лучше не использовать. dpkg (если
делать рут на btrfs) страшно тормозит, и чинить это никто не будет.

И все это касается в том числе и свежих ядер, в смысле, более свежих,
чем в stable.

Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
машинке быстрый SATA-выход один.

Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs,
не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают
лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо
zfs (и btrfs) динамически распределяют под них место, но что-то тоже
практического применения не сложилось.

А вот косой взгляд на инструменты out-of-band deduplication для btrfs
как раз вызывает интерес к оной файловой системе. Поскольку там немало
бэкапов, и порой файлы в них переезжают, эта функциональность
представляется нелишней. Расслабиться на тему "ну и что, что сотню
гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
приятно.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

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

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Alex Kicelew
In reply to this post by Artem Chuprina-4
On 11/1/18 8:54 PM, Artem Chuprina wrote:
> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

Непосредственно сейчас не скажу, но год-полтора назад, когда я несколько
неупорядоченно уползал с extN, на одной машине я экспериментировал и с
btrfs. Поломалась примерно через полтора месяца после установки. Всех
подробностей не помню, но точно помню как небольшое количество
неудаляемых файлов и директорий (rm/rmdir вылетал с ошибкой и
маловразумительной руганью в логи), так и небольшое количество файлов с
перепутанным содержимым, например, текстовый .tar.gz, который я создать
именно в таком виде навряд ли мог. Это был рабочий ноут со
среднепрограммерским паттерном использования, из особенностей
использовались дедупликация, cp --reflink и сенд бэкапов на соседнюю
машину. Какое именно действие поломало, установить не удалось.

Снес и больше не пробовал.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Alexander Wiedergold WIEDERGOLD.NET Administrator
In reply to this post by Igor Savlook
привет,
может кто помочь?
как это быстро исправить? или нужно всегда выполнять: 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
>> как раз вызывает интерес к оной файловой системе. Поскольку там немало
>> бэкапов, и порой файлы в них переезжают, эта функциональность
>> представляется нелишней. Расслабиться на тему "ну и что, что сотню
>> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
>> приятно.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

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

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Alexander Gerasiov-3
In reply to this post by Artem Chuprina-4
Hello Artem,

On Thu, 01 Nov 2018 20:54:25 +0300
Artem Chuprina <[hidden email]> wrote:

> Хмутро.
>
> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
4.18) и вроде всё устраивает. Кроме того, она активно используется в
качестве backend для sbuild очень много у кого.


[gq@dwarf:~/ya/sdc]$ mount | grep btrfs
/dev/mapper/dwarf-root on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
/dev/mapper/dwarf-chroot on /srv/chroot type btrfs (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
/dev/mapper/dwarf-home on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
/dev/mapper/dwarf-tmp on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
> машинке быстрый SATA-выход один.
Под надежный сторадж я использую ext4. Он же надёжный =)

> А вот косой взгляд на инструменты out-of-band deduplication для btrfs
> как раз вызывает интерес к оной файловой системе. Поскольку там немало
> бэкапов, и порой файлы в них переезжают, эта функциональность
> представляется нелишней. Расслабиться на тему "ну и что, что сотню
> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
> приятно.

Вот с этим как-то всё непонятно: тоже всё хотел использовать, но то
утилита требовала каких-то особых танцев, то грозила потерей данных, то
падала с непонятной диагностикой. В итоге так и не заюзал.


--
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: [hidden email]  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Artem Chuprina-4
Угу, осознал. Всем спасибо, переформатировал в ext4 и ограничусь
перелинковкой средствами jdupes. Из положительного: в процессе чтения
про дедупликацию у btrfs выяснил, что существуют готовые инструменты для
такой перелинковки (не зависящие от btrfs), не надо писать :)

 >> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

 > Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
 > но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
 > 4.18) и вроде всё устраивает. Кроме того, она активно используется в
 > качестве backend для sbuild очень много у кого.


 > [gq@dwarf:~/ya/sdc]$ mount | grep btrfs
 > /dev/mapper/dwarf-root on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-chroot on /srv/chroot type btrfs
 > (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-home on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-tmp on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

 >> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
 >> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
 >> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
 >> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
 >> машинке быстрый SATA-выход один.
 > Под надежный сторадж я использую ext4. Он же надёжный =)

 >> А вот косой взгляд на инструменты out-of-band deduplication для btrfs
 >> как раз вызывает интерес к оной файловой системе. Поскольку там немало
 >> бэкапов, и порой файлы в них переезжают, эта функциональность
 >> представляется нелишней. Расслабиться на тему "ну и что, что сотню
 >> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
 >> приятно.

 > Вот с этим как-то всё непонятно: тоже всё хотел использовать, но то
 > утилита требовала каких-то особых танцев, то грозила потерей данных, то
 > падала с непонятной диагностикой. В итоге так и не заюзал.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

artiom
Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и
бета версиями уже долго, потому если требуется подобный функционал, ясно
что выбирать.

02.11.2018 18:19, Artem Chuprina пишет:

> Угу, осознал. Всем спасибо, переформатировал в ext4 и ограничусь
> перелинковкой средствами jdupes. Из положительного: в процессе чтения
> про дедупликацию у btrfs выяснил, что существуют готовые инструменты для
> такой перелинковки (не зависящие от btrfs), не надо писать :)
>
>   >> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?
>
>   > Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
>   > но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
>   > 4.18) и вроде всё устраивает. Кроме того, она активно используется в
>   > качестве backend для sbuild очень много у кого.
>
>
>   > [gq@dwarf:~/ya/sdc]$ mount | grep btrfs
>   > /dev/mapper/dwarf-root on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
>   > /dev/mapper/dwarf-chroot on /srv/chroot type btrfs
>   > (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
>   > /dev/mapper/dwarf-home on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
>   > /dev/mapper/dwarf-tmp on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
>
>   >> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
>   >> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
>   >> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
>   >> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
>   >> машинке быстрый SATA-выход один.
>   > Под надежный сторадж я использую ext4. Он же надёжный =)
>
>   >> А вот косой взгляд на инструменты out-of-band deduplication для btrfs
>   >> как раз вызывает интерес к оной файловой системе. Поскольку там немало
>   >> бэкапов, и порой файлы в них переезжают, эта функциональность
>   >> представляется нелишней. Расслабиться на тему "ну и что, что сотню
>   >> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
>   >> приятно.
>
>   > Вот с этим как-то всё непонятно: тоже всё хотел использовать, но то
>   > утилита требовала каких-то особых танцев, то грозила потерей данных, то
>   > падала с непонятной диагностикой. В итоге так и не заюзал.
>

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Artem Chuprina-4
artiom -> [hidden email]  @ Sat, 3 Nov 2018 16:10:09 +0300:

 > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
 > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и бета
 > версиями уже долго, потому если требуется подобный функционал, ясно что
 > выбирать.

Ну вот у меня, например, при загрузке системы упорно не монтируется один
из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
то молча монтируется. Отличается от остальных тем, что там попрошено
case insensitive имена файлов (это exchange, в первую очередь для винды)
и задействованы ACL.

Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
и монитор к нему цеплять неудобно.

Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
умеет. Под ин-бэнд требования к железу невменяемые. А прочие плюшки ZFS
по сравнению с той же ext4 как-то применить не удается — машинка
слабенькая, без ECC, диск один, так что чексуммы все равно лучше держать
внешние, и проверять после скидывания на бэкапный винт.

При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
если инитом работает systemd, а systemd инитом весьма хреново
работает. Описанная проблема с нецеплянием одного из томов — не
единственная проблема с systemd на этой машине. Это я уж молчу про танцы
с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
нравится.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

artiom


03.11.2018 20:27, Artem Chuprina пишет:

> artiom -> [hidden email]  @ Sat, 3 Nov 2018 16:10:09 +0300:
>
>   > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
>   > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и бета
>   > версиями уже долго, потому если требуется подобный функционал, ясно что
>   > выбирать.
>
> Ну вот у меня, например, при загрузке системы упорно не монтируется один
> из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
> то молча монтируется. Отличается от остальных тем, что там попрошено
> case insensitive имена файлов (это exchange, в первую очередь для винды)
> и задействованы ACL.
> Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
> и монитор к нему цеплять неудобно.
>

А монитор-то зачем, если залогиниться возможно без примонтированного тома?
Кстати, точка монтирования пустая?

> Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
> умеет.

Да, есть такое, предлагают делать через zfs send, но велик ли уровень
фрагментации для большинства задач?


> Под ин-бэнд требования к железу невменяемые.

Это про что? Про дедап?


> А прочие плюшки ZFS
> по сравнению с той же ext4 как-то применить не удается — машинка
> слабенькая, без ECC, диск один, так что чексуммы все равно лучше держать
> внешние, и проверять после скидывания на бэкапный винт.
>

Помню, тема была, и в ней таки пришли, что лучше ZFS.
Но да, без ECC не стоит. Да и ext4 в данном случае ничего гарантировать
не может.

> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
> если инитом работает systemd, а systemd инитом весьма хреново
> работает.

Ну как-бы он сейчас меинстрим, хоть как-то да работает.

> Описанная проблема с нецеплянием одного из томов — не
> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
> нравится.
>

Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Artem Chuprina-4
artiom -> [hidden email]  @ Thu, 8 Nov 2018 23:07:09 +0300:

 >>   > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
 >>   > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и бета
 >>   > версиями уже долго, потому если требуется подобный функционал, ясно что
 >>   > выбирать.
 >>
 >> Ну вот у меня, например, при загрузке системы упорно не монтируется один
 >> из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
 >> то молча монтируется. Отличается от остальных тем, что там попрошено
 >> case insensitive имена файлов (это exchange, в первую очередь для винды)
 >> и задействованы ACL.
 >> Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
 >> и монитор к нему цеплять неудобно.
 >>

 > А монитор-то зачем, если залогиниться возможно без примонтированного тома?

Чтобы разобраться, что происходит в момент загрузки.

 > Кстати, точка монтирования пустая?

Пустая.

 >> Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
 >> умеет.

 > Да, есть такое, предлагают делать через zfs send, но велик ли уровень
 > фрагментации для большинства задач?

Тьфу. Дедупликацию.

 >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
 >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
 >> если инитом работает systemd, а systemd инитом весьма хреново
 >> работает.

 > Ну как-бы он сейчас меинстрим, хоть как-то да работает.

Угу. При каждой загрузке сервера приходится потом логиниться, вручную
домонтировать том ZFS, передергивать самбу и nfsd (они раздают в том
числе эту директорию, и не умеют отследить, что туда что-то
подмонтировали), и поднимать не запустившийся по столь же неизвестным
причинам rsyncd.

Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
проблема в этом, потому что про "как повезет" есть уверенность.

 >> Описанная проблема с нецеплянием одного из томов — не
 >> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
 >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
 >> нравится.

 > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.

Загружает. Устанавливать систему в эту позу (например, если придется
поднимать с бэкапа) неудобно. Много ручных танцев.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

artiom
>
>   >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
>   >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
>   >> если инитом работает systemd, а systemd инитом весьма хреново
>   >> работает.
>
>   > Ну как-бы он сейчас меинстрим, хоть как-то да работает.
>
> Угу. При каждой загрузке сервера приходится потом логиниться, вручную
> домонтировать том ZFS, передергивать самбу и nfsd (они раздают в том
> числе эту директорию, и не умеют отследить, что туда что-то
> подмонтировали), и поднимать не запустившийся по столь же неизвестным
> причинам rsyncd.
>
> Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
> systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
> проблема в этом, потому что про "как повезет" есть уверенность.
>

Вообще, как бы неприятен systemd не был, но он всё-таки предназначен для
отслеживания зависимостей и управления ими множеством способов.
Так что, есть подозрение, что тут не в его сторону надо смотреть, а на
описание сервиса.
Возможно, что именно там зависимости прописаны криво.

>   >> Описанная проблема с нецеплянием одного из томов — не
>   >> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
>   >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
>   >> нравится.
>
>   > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.
>
> Загружает. Устанавливать систему в эту позу (например, если придется
> поднимать с бэкапа) неудобно. Много ручных танцев.
>

Ну, кажется, для бэкапа, вы же сами мне рекомендовали сохранять образ
полностью. В этом случае, проблем нет.

Reply | Threaded
Open this post in threaded view
|

Re: btrfs?

Artem Chuprina-4
artiom -> [hidden email]  @ Sat, 10 Nov 2018 16:29:16 +0300:

 >>   >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
 >>   >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
 >>   >> если инитом работает systemd, а systemd инитом весьма хреново
 >>   >> работает.
 >>
 >>   > Ну как-бы он сейчас меинстрим, хоть как-то да работает.
 >>
 >> Угу. При каждой загрузке сервера приходится потом логиниться, вручную
 >> домонтировать том ZFS, передергивать самбу и nfsd (они раздают в том
 >> числе эту директорию, и не умеют отследить, что туда что-то
 >> подмонтировали), и поднимать не запустившийся по столь же неизвестным
 >> причинам rsyncd.
 >>
 >> Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
 >> systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
 >> проблема в этом, потому что про "как повезет" есть уверенность.
 >>

 > Вообще, как бы неприятен systemd не был, но он всё-таки предназначен для
 > отслеживания зависимостей и управления ими множеством способов.
 > Так что, есть подозрение, что тут не в его сторону надо смотреть, а на
 > описание сервиса.
 > Возможно, что именно там зависимости прописаны криво.

С виду — прямо.

 >>   >> Описанная проблема с нецеплянием одного из томов — не
 >>   >> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
 >>   >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
 >>   >> нравится.
 >>
 >>   > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.
 >>
 >> Загружает. Устанавливать систему в эту позу (например, если придется
 >> поднимать с бэкапа) неудобно. Много ручных танцев.

 > Ну, кажется, для бэкапа, вы же сами мне рекомендовали сохранять образ
 > полностью. В этом случае, проблем нет.

Иногда бывает, что бэкапный винт меньше рабочего, и бэкап приходится
делать выборочным. Было бы куда сохранить полный...

И второй момент. При восстановлении на железо, от которого не было
фирмвари, образ винта может не взлететь. В этой ситуации надо уметь
подмонтировать его с rescue-флешки. Для ZFS надо вместо rescue брать
live и доставлять в нее zfs-dkms.

Оно бы окупалось, если бы какие-то функции ZFS, которых нету у ext4,
прижились. А так — нет.