BTRFS

[thunderamur]

Последнее время активно пробую работать с BTRFS, после того как сделал тест её быстродействия и эффективности сжатия на Ubuntu 16.04 alpha (kernel 4.2). В результате получил ускорение загрузки системы с HDD с 20 секунд на EXT4, до 17 секунд на BTRFS без сжатия и до 14 секунд на BTRFS со сжатием lzo. Коэффициент сжатия для корня системы 1.5-2 раза при использовании lzo.
http://forum.ubuntu.ru/index.php?topic=269710.0

Сейчас поставил ROSA Fresh R6 на ноут с Intel Celeron N2830 (2x2.41 turbo Bay-Trail), это довольно слабый процессор, немного сильнее атомов, на смену которым он пришел. Также протестил загрузку с HDD. В случае с этим слабым конфигом загрузка ROSA с BTRFS без сжатия получилась 64 секунды до проигрывания мелодии входа в систему, со сжатием lzo 62 секунд. Т.е. без изменений в скорости загрузки, зато коффициент сжатия составил 0.57 (было 6.8 ГБ вместе с /home, стало 3.9 ГБ).

Исходя из этого можно с уверенностью сказать, что:
1 .Слабые нетбуки на старых атомах получат некоторое снижение производительности при использовании сжатия. Ноуты же с более мощными процессорами i3 и выше (и тем более ПК с мощными настольными процессорами) выиграют в производительности работы дисковой подсистемы.
2. BTRFS без сжатия быстрее EXT4. BTRFS со сжатием значильно быстрее EXT4 на мощных процессорах.
3. BTRFS со сжатием экономит дисковое пространство в 1.5-2 раза для системного раздела.

Товарищи, пробуйте использовать BTRFS и делитесь своими наблюдениями, похоже ФС все-таки доделали, а то несколько лет назад была печаль с производительностью. Только не забудьте поставить ядро посвежее, для BTRFS регулярно вносятся улучшения в ядро.

[Delles]

Интересно было бы узнать, как она работает на внешних жестких дисках и флешках. Насколько проворна, сколько отъедает под служебную информацию, насколько надежна, кому принадлежит по умолчанию после форматирования (руту или юзеру), способен ли ее видеть кто-либо, кроме Линукса.

[ans]

Товарищи, пробуйте использовать BTRFS и делитесь своими наблюдениями, похоже ФС все-таки доделали, а то несколько лет назад была печаль с производительностью.

Второй год уже использую. Причём Роса автоматом устанавливает BTRFS при инсталляции.
Перед тем как форматировать разделы по умолчанию для корневого стоит EXT4, а для home стоит btrfs.

[Yamah]

Btrfs на десктопе с 2013 года. корень, usr, var, opt, home, разделах с музыкой, видео и фотками.
С 2015 года на SSD. При сжатии заметил незначительное падение производительности на AMD X8 FX-8350 4000MH. Загрузка при использовании сжатия длиться секунд 15, а без оного 10-12.
На нетбуке Samsung N127 (Atom) потеря производительности с лихвой компенсируется сжатием. В итоге, на 32 ГБ отведенных под систему, 34 ГБ занимают данные и 16 GB свободно.

Помимо прочего на домашнем сервере (увы, там Debian, нужно было свежее ядро, пропатченный Apache, и еще куча ПО, которого нет в RELS), помимо сжатия используется функции Raid-массива и субтомов.

Без снапшотов на десктопе я уже не могу. Несколько раз приходилось откатываться после неудачных пятничных обновлений. Три попытки протестировать KDE5 проходили в с специально созданном снапшоте.

Метаданных на одном физическом разделе под торрентами не так много отжирается. Но вот при использовании raid в связке -d 0 -m 1 может отожрать процентов 10 от размера тома. (Полдня проискал, куда за сутки делись 200 гигов: было 500 гигов свободно, 200 гигов было загружено, осталось 100 гигов, BTRFS в dфеф Raid-0, metadata Raid-1)

[Yamah]

Товарищи, пробуйте использовать BTRFS и делитесь своими наблюдениями, похоже ФС все-таки доделали, а то несколько лет назад была печаль с производительностью.

Второй год уже использую. Причём Роса автоматом устанавливает BTRFS при инсталляции.
Перед тем как форматировать разделы по умолчанию для корневого стоит EXT4, а для home стоит btrfs.

Еще в R5 сжатие и использование подтома можно было включить только вручую набрав в дополнительных опциях параметр compress=lzo,subvol=@RosaFresh

[Xakep]

При сжатии заметил незначительное падение производительности на AMD X8 FX-8350 4000MH. Загрузка при использовании сжатия длиться секунд 15, а без оного 10-12.

Тоже сейчас попробовал эту BTRFS и пришел практически к таким же результатам. У меня AMD X8 FX-8320 3500MH.
К сожалению для меня эта ФС пока не пойдет (хотя она очень заманчива), и по банальной причине, эту ФС практически нечем прочитать из под Win-ды (а для меня это очень актуально)...

[thunderamur]

Yamah, Xakep
С каким ядром делали замеры? Это очень важно в случае BTRFS. На Ubuntu у меня было ядро 4.2, в РОСА 4.1.

[Xakep]

Yamah, Xakep
С каким ядром делали замеры? Это очень важно в случае BTRFS. На Ubuntu у меня было ядро 4.2, в РОСА 4.1.

У меня

Код: Выделить всё

$ uname -r
4.2.6-nrj-desktop-1rosa-x86_64

[Vochatrak]

Народ, а можно соединить в один пулл два харда, разного размера и с раной скоростью чтения\записи?
И такой вопрос - если два диска объединены и один сдох, всем данным кещельбере, или только тем что были на сдохшем?

[notauser]

Yamah, Xakep
С каким ядром делали замеры? Это очень важно в случае BTRFS. На Ubuntu у меня было ядро 4.2, в РОСА 4.1.

Не забудьте сравнить версию systemd.

[neobht]

Народ, а можно соединить в один пулл два харда, разного размера и с раной скоростью чтения\записи?
И такой вопрос - если два диска объединены и один сдох, всем данным кещельбере, или только тем что были на сдохшем?

Если зеркальный рейд, то только той копии, что была на сдохшем. Если рейд другого типа, то там сложнее - на глаз не определишь, но однозначно - ситуация будет печальной.

[Vochatrak]

Если зеркальный рейд,

А их обязательно именно в ред масив соединять?
Вроде можно просто смержить два раздела в один (в смысле без "шахматной записи")
Поправьте если я не прав.

[trs]

Если в документации сказано, что можно смержить, но на практике не выйдет - значит будет право говорить об ошибке реализации.

[Yamah]

Yamah, Xakep
С каким ядром делали замеры? Это очень важно в случае BTRFS. На Ubuntu у меня было ядро 4.2, в РОСА 4.1.

3.19.*, 4.0.*, 4.1.*

Народ, а можно соединить в один пулл два харда, разного размера и с раной скоростью чтения\записи?
И такой вопрос - если два диска объединены и один сдох, всем данным кещельбере, или только тем что были на сдохшем?

Можно. Но лучше так не делать.
Зеркалиться или расширяться будут только те данные, что попадают в объем меньшего диска.
При выходе из строя одного из дисков, теоретически можно восстановить данные на втором штатными средствами BTRFS, при условии, что метаданные зеркалились.
Однако, если у вас был Raid-0, данные, которые попадали на оба диска, скорее всего будут потеряны.

Если зеркальный рейд,

А их обязательно именно в ред масив соединять?
Вроде можно просто смержить два раздела в один (в смысле без "шахматной записи")
Поправьте если я не прав.

По-моему, по умолчанию для одного раздела на нескольких дисках включается raid. Но какой уровень не помню.
Искать нужно инфу по балансировке.

[trs]

Да, инфу искать было бы здорово, может и балансировка не нужна

A Btrfs filesystem can be created on top of many devices, and more devices can be added after the FS has been created.
By default, metadata will be mirrored across two devices and data will be striped across all of the devices present.

Файловая система Btrfs может быть создана поверх многих устройств, и диски могут быть добавлены после того, как Btrfs создана.
По умолчанию (??? — прим. мое) , метаданные будут зеркалированы между двумя устройствами, а данные расслоены (RAID0) между всеми присутствующими устройствами.

Код: Выделить всё

# Create a filesystem across four drives (metadata mirrored, linear data allocation)
# Создать ФС на 4х приводах (метаданные заркалированы, данные расположены линейно, т.е. нет RAID)
mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Stripe the data without mirroring
mkfs.btrfs -d raid0 /dev/sdb /dev/sdc

https://btrfs.wiki.kernel.org/index.php ... le_Devices

[thunderamur]

Тема о BTRFS на убунтуфоруме получила развитие. Я запилил уже 2 теста, один на мощном десктопе, 2-й на дохлом ноуте, даже на нем сжатие lzo дает бонус в скорости при работе с HDD.
http://forum.ubuntu.ru/index.php?topic=269699.0 (ссылки на тесты в конце 1-го поста)

[Vochatrak]

А Lz4 в BTRFS добавить можно? Видел раньше патчи, но самому пересобирать как-то страшновато, ФС все-таки.
Не у кого нет .rpm-а готового?

[trs]

В худшем случае, после патча не должно собираться (это если патчить версию отличную от той, на которую рассчитан патч) хотя, скорее, ошибку выдаст patch. Потому не так важно, кто будет накатывать патч, сборщик rpm, или самостоятельно. А проверить можно, установив (скопировав) систему на флешку, или в виртуальную машину.

[Xakep]

Очень старая (аж от 2009г.), но, большая (5 страниц) и познавательная статья о BTRFS - http://citkit.ru/articles/1231/

[Yamah]

На ядрах 4.1.15 и выше с BTRFS с сжатием на слабом железе (Samsung N127) работать стало невозможно физически.
Любая работа с ПО, использующее СУБД будь-то BDB или SQLite просто зависает. Особенно печально это для URPMI.

На более-менее сильном железе BTRFS нет равных в Linux. Возможно еще будет ZFS хорошей, но пока реализация в Linux слабая.

[r0g3r]

Не скажу за всех, но btrfs со сжатием на CentOS 7 ломает ФС. Причём непредсказуемо. Может, конечно, на более свежих версиях ядер и утилит btrfs это исправлено, но просто имейте в виду.

[trs]

На ядрах 4.1.15 и выше с BTRFS с сжатием на слабом железе (Samsung N127) работать стало невозможно физически.
Любая работа с ПО, использующее СУБД будь-то BDB или SQLite просто зависает.

Возможно, проблему с БД решает --nodesize, соответствующий по размеру страницам БД. По крайней мере, руководства по ZFS рекомендуют recordsize выбирать таким образом. Хотя на подобном слабом железе я никаких специальных настроек для оптимизации urpmi не делал, и проблем не замечено.

[Vochatrak]

Народ, ничего не понимаю!
У меня хомяк btrfs со сжатием. Показывает что свободно еще 5.6Gb. Начинаю копировать файлы, так оно мне пишет что нет свободного места.
Что за выкрутасы?

[trs]

Сталкивался с таким. Часть свободного места резервируется под нужды системы (в моём случае было 11%). Вам еще повезло, что пишет в явном виде про нехватку места, у меня молча создался битый initrd... На документацию ссылку не дам, но, если правильно помню, это "нормальное поведение".

[Vochatrak]

На документацию ссылку не дам, но, если правильно помню, это "нормальное поведение".

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

[Yamah]

Что за выкрутасы?

Метаданные сжирают вероятнее всего.

Код: Выделить всё

btrfs filesystem df /home

что говорит?

[trs]

А нельзя сделать что-бы он зарезервированное место не показывал свободным? А то так и до беды недалеко.

Поискал FAQ https://btrfs.wiki.kernel.org/index.php ... k_space.21
Если нет желания вникать во всё написанное, то приведу ключевую фразу: "We know this isn't ideal, and there are plans to improve the behavior.". То есть -- это в планах.

Метаданные сжирают вероятнее всего.

Свободное место, оно же для данных пользователя. То есть метаданные -- отдельно. Но судя по FAQ, метаданные действительно сжирают место, под них отведённое. А свободное ничем не занято, просто нет возможности его использовать.

[Yamah]

Без использования RAID

Код: Выделить всё

$ sudo fdisk -l /dev/sda                                                                                                                                                                               

Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors                                                                                                                                                     
Units: sectors of 1 * 512 = 512 bytes                                                                                                                                                                               
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                                                                                               
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                                                                                   
Disklabel type: gpt                                                                                                                                                                                                 
Disk identifier: CEDDD136-5C0B-4385-AC60-3D532164C8E6                                                                                                                                                               

Устр-во          Start   Конец   Size Тип                                                                                                                                                                           
/dev/sda1       526336    231233535   110G Linux filesystem                                                                                                                                                         
/dev/sda2         2048       526335   256M EFI System                                                                                                                                                               
/dev/sda3    231233536    250069646     9G Linux swap                                                                                                                                                               

$ mount | grep /dev/sda1
/dev/sda1 on / type btrfs (rw,noatime,ssd,space_cache,subvolid=297,subvol=/@Rosa_Fresh)
/dev/sda1 on /mnt/Steam/SSD type btrfs (rw,noatime,ssd,space_cache,subvolid=259,subvol=/@Steam)
/dev/sda1 on /mnt/Zone/Home/SSD type btrfs (rw,noatime,ssd,space_cache,subvolid=258,subvol=/@Home)
/dev/sda1 on /mnt/Zone/System type btrfs (rw,noatime,ssd,space_cache,subvolid=5,subvol=/)

$ df -h /mnt/Zone/System                                                                                                                                                                               
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в                                                                                                                                             
/dev/sda1          111G          45G   64G           42% /mnt/Zone/System         
                                                                                                                                  
$ sudo btrfs filesystem df /mnt/Zone/System                                                                                                                                                            
Data, single: total=59.01GiB, used=43.07GiB                                                                                                                                                                         
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=3.01GiB, used=1.31GiB
GlobalReserve, single: total=464.00MiB, used=0.00B

$ sudo btrfs filesystem show /mnt/Zone/System
Label: 'System'  uuid: db2cb0bb-e9ad-4732-9c92-15cfce2358b8
        Total devices 1 FS bytes used 44.39GiB
        devid    1 size 110.01GiB used 62.02GiB path /dev/sda1

Как можно увидеть Утилита DF реально отображает место под данные и метаданные

Там где есть RAID

Код: Выделить всё

$ sudo df /home/Profiles
Файловая система  1K-блоков Использовано  Доступно Использовано% Cмонтировано в
/dev/sda1        1920157696   1604434944 313889608           84% /home/Profiles
$ sudo btrfs filesystem df /home/Profiles
Data, RAID0: total=267.44GB, used=261.47GB
Data: total=1.52TB, used=1.23TB
System, DUP: total=8.00MB, used=212.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=512.00MB, used=504.45MB
Metadata, DUP: total=2.62GB, used=2.01GB
Metadata: total=8.00MB, used=0.00

[trs]

Там где есть RAID

Код: Выделить всё

$ sudo df /home/Profiles
Data: total=1.52TB, used=1.23TB

Metadata, DUP: total=2.62GB, used=2.01GB

Тут данные и метаданные пропорционально заполнены. Повезло.
Бывает и так, что метаданные заполняются быстрее:

if your device is large (>16GiB)
If the filesystem has allocated (but not used) all of the available space, and the metadata is close to full, then df can show lots of free space, but you may still get out of space errors because there isn't enough metadata available.

Что с этим делать -- вот в чём вопрос.

[Vochatrak]

btrfs filesystem df /home
что говорит?

Код: Выделить всё

# btrfs filesystem df /home
Data, single: total=79.01GiB, used=73.09GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=525.50MiB, used=283.69MiB
GlobalReserve, single: total=96.00MiB, used=0.00B

Я конечно не спец, но по моему не сходится.
На всякий пожарный, прогнал btrfsck и btrfs scrub - все вроде в норме.

Кстати, все хотел спросить - а балансировку вообще стоит делать?

[trs]

В FAQ, по ссылке, даже если слова английские не понятны, то команды должны быть знакомы:

If you have full up metadata, and more than 1 GiB of space free in data, as reported by btrfs fi df, then you should be able to free up some of the data allocation with a partial balance:

Код: Выделить всё

# btrfs balance start /mountpoint -dlimit=3

"Если метаданные заполнены, но, согласно выводу btrs fi df, более 1Гб свободно, должна помочь частичная балансировка"

[Vochatrak]

В FAQ, по ссылке, даже если слова английские не понятны, то команды должны быть знакомы:

Потому и спрашивал:

Кстати, все хотел спросить - а балансировку вообще стоит делать?

[trs]

Не скажу за всех, но btrfs со сжатием на CentOS 7 ломает ФС. Причём непредсказуемо. Может, конечно, на более свежих версиях ядер и утилит btrfs это исправлено, но просто имейте в виду.

Кое-что исправлено в 4.4.8:

Код: Выделить всё

    Btrfs: fix file/data loss caused by fsync after rename and new inode
    
    commit 56f23fdbb600e6087db7b009775b95ce07cc3195 upstream.
    
    If we rename an inode A (be it a file or a directory), create a new
    inode B with the old name of inode A and under the same parent directory,
    fsync inode B and then power fail, at log tree replay time we end up
    removing inode A completely. If inode A is a directory then all its files
    are gone too.

https://cdn.kernel.org/pub/linux/kernel ... eLog-4.4.8

[Ansy]

Решился на btrfs на рабоче/походном ноуте. Ибо системе в / некуда всунуть было уже обновления и новый софт, /home слегка пустовал, а при инсталляции автосозданный swap-раздел вообще не использовался (оперативки стало 2GB).
Сейчас один большой / "на всё про всё" под btrfs.
Как рекомендуете -- есть смысл выделять /home или ещё что-то в отдельные subvolumes?
Надо ли какие-то особые параметры монтирования кроме default?
Может быть определенные файлы или каталоги нуждаются в некоторых особых атрибутах?

[Vochatrak]

Как рекомендуете -- есть смысл выделять /home или ещё что-то в отдельные subvolumes?

Есть. Хомяк всегда нужно держать на отдельном разделе/субволюме.

Надо ли какие-то особые параметры монтирования кроме default?

Ну, это уже по личным предпочтениям. Однако, рекомендую - поменять цифры на 0 0, еще не лишним будет добавить autodefrag и space_cache.
Вот такое прописано у меня

Код: Выделить всё

/ btrfs nofail,relatime,compress=lzo,autodefrag,space_cache 0 0

Удачи.

[Алзим]

Хомяк всегда нужно держать на отдельном разделе/субволюме.

Да. И именно так. И никак иначе.
И нужно помнить, что Линукс — это не Винда. Переустановка системы может не помочь.
Если есть проблемы, то надо сначала создать другого пользователя и смотреть у него.
Если у него есть проблемы, то переустанавливать систему. Если у другого пользователя нет проблем, то чистить своего Хомяка — переустановка не поможет.

[Yamah]

Хомяк лучше держать на отдельном диске. Если нет возможности, то на отдельном разделе. Забивать пользовательскими раздел с системой лучше не надо.

Если есть возможность использовать комбинацию SSD+HDD, то лучшее ее использовать через aufs: на SSD только данные необходимые для загрузки профиля, все остальное на HDD.

[Алзим]

Про SDD много писать не буду, т.к. у меня его нет.
Если SDD маленького объёма, то я бы его использовал как виртуальную память.

[trs]

Если SDD маленького объёма, то я бы его использовал как виртуальную память.

ZFS позволяет использовать накопитель в качестве кэша (похоже на ReadyBoost), имеется ввиду нечто подобное? Это можно реализовать для произвольных ФС?

И на минуточку, отвлекёмся от страшилок:

Код: Выделить всё

9 Power_On_Hours          -O--C-   100   100   000    -    28261

то есть примерно 3 года, если считать включенное состояние.
Это "медленные", "древние", "ненедёжные" и т.п. накопители.
https://www.linux-hardware.org/index.ph ... g=smartctl
На одном из двух возникла единственная ошибка записи — на 790й день. И то не ясно, по какой причине, условия эксплуатации бывают экстремальными.

[Ansy]

ZFS позволяет использовать накопитель в качестве кэша (похоже на ReadyBoost), имеется ввиду нечто подобное? Это можно реализовать для произвольных ФС?

Для ZFS у меня оперативки не так много... а вот на BTRFS такое возможно ли? И как именно сделать?

[trs]

28 октября вышла версия v0.7.0-rc2 ZFS, где управление памятью переработано и адаптировано под Linux. RC2 не рекомендована для широкого использования, но отлаженный выпуск уже не за горами. После чего страшилки о "пожирании памяти" потеряют теоретическое обоснование. На практике же я использовал ZFS с 1ГБ ОЗУ.

Возможно ли использование твердотельного накопителя в качестве кеша на BtrFS, мне и самому интересно, я такой информации не нашел (но и не особо искал).

[Molchun]

А есть ли в Роса инструмент подобный Убунтовскому apt-btrfs-snapshot ?

[trs]

Вы бы лучше сообщили, зачем оно надо и как работает.
Как я понял из описания, служит для атомарного обновления системы.
Но реализовано исключительно для BtrFS.
Тут есть ROSA Freeze, можно "заморозить" содержимое диска для проверки нового ПО.
Не так удобно, но ФС произвольная.

[Molchun]

Ну, главным образом, как я понял, оно нужно для автоматического создания снапшота после установки какого либо пакета в систему или обновлении оного.
Это на мой взгляд очень удобно.
Во вторых, с помощью него можно установить предыдущий снапшот не выходя из системы а потом просто перезагрузиться чтоб снапшот вступил в силу.
Так же apt-btrfs-snapshot избавляет от лишних движений с монтированием. В общем и целом упрощает работу с снапшотами.
А ROSA Freeze в некоторых случаях абсолютно не подходит.
Например проверить новое ядро, графический драйвер и т.д. (там где нужна перезагрузка)

[trs]

Снимки ФС создаются с определённой целью.
Можно ведь и по расписанию снапшотить каждый день, такой сценарий больше подходит для данных пользователя, а не компонентов ОС.

Я было решил, что Вы это использовали — в таком случае было бы интересно узнать об опыте и нюансах, что выявлены на практике.
В git-репозитории настораживают даты обновления, несколько лет назад.
И по какой-то причине не интегрировано в систему, как, к примеру, в TrueOS:

В РОСА при обновлении ядра предыдущее не удаляется и может быть выбрано в меню GRUB.

А вот при обновлении видеодрайверов, действительно, бывают проблемы. В таком случае рекомендуется зайти в терминал Alt+Ctrl+F2 и переустановить драйвер, запустив XFdrake. Насколько я понимаю, в случае с apt-btrfs-snapshot сценарий схож, лишь команда в консоли отличается?

[Molchun]

Снимки ФС создаются с определённой целью.

Абсолютно согласен.

Можно ведь и по расписанию снапшотить каждый день, такой сценарий больше подходит для данных пользователя, а не компонентов ОС.

В том то и дело, что для меня компоненты системы стоят на первом месте и в моём случае снапшотить по расписанию не логично и нецелесообразно.

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

В настоящий момент принимаю решение о переходе на btrfs и в свете этого всесторонне изучаю данный вопрос. Возраст когда с шашкой на голо уже прошёл.

А вот при обновлении видеодрайверов, действительно, бывают проблемы. В таком случае рекомендуется зайти в терминал Alt+Ctrl+F2 и переустановить драйвер, запустив XFdrake. Насколько я понимаю, в случае с apt-btrfs-snapshot сценарий схож, лишь команда в консоли отличается?

Я знаю как вернуть в чувство систему после проблем с видеодрайвером. Да, сценарий схож, но телодвижений в разы меньше. А я вообще сторонник того, что если есть инструмент или возможность сделать что-то проще - то зачем усложнять.

[Yamah]

А есть ли в Роса инструмент подобный Убунтовскому apt-btrfs-snapshot ?

Частично есть! Берете этот скрипт, исправляете пути до точки монтирования вашего корневого диска и пользуетесь. В тихом режиме делает снапшот подтома с корнем текущей ОС в каталог в корне ФС с именем подтома и суффиксом в виде текущей даты.
Скрипт для восстановления мне писать было влом.

В нормальное автоматическое восстановление изменением всех конфигов загрузки на другой снапшот я не верю. Тем более, что от этого снапшоты "портятся". Проще ручками из внешней ОС сделать снапшот с именем подтома с нужного снапшота.

[Ansy]

Гуры, выручайте -- я чот упёрся... не могу поставить РОСУ на BTRFS/RAID1, ибо GRUB2 не грузится на разных стадиях.
Как диски-то разбить правильно?

Задача исходно такая. Есть комп AMD 8 ядер/8GB/UEFI, только что умер HDD с Виндой, мир их праху обоим.

Есть два других HDD, с которыми некоторые нюансы.
Первый /dev/sda Hitachi 400GB в хорошем состоянии, но достаточно старая модель, и потому тормозной.
Второй /dev/sdb Seagate 500GB уже с бэдблоками, привит от "мухи ЦеЦе" -- пошустрее, но доверия ему поменьше.

Надо поставить ROSA Fresh Desktop KDE x86-64. Можно UEFI (никогда с ней не ставил, не факт что не глючит), можно просто Legacy BIOS.

Хочу весь первый винт /dev/sda отдать по максимуму под / и форматнуть в BTRFS.
На втором винте /dev/sdb выделить раздел того же размера, что и на первом, и сделать RAID1, типа вот так mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sdb1
Включить lzo-компрессию, выделить subvolume для /home и возможно для / (есть смысл? снапшотить, например?)
При таком раскладе рассчитываю, как минимум, ускорить дисковую систему, а также не потерять данные при отказе любого из винтов.

Остаток второго HDD в сотню GB отдать под NTFS для образов виртуалок, в т.ч. с Виндой (нужна, блин), обмена данными с другими системами, ну и файликом swap сделать (на ноуте так работает).

Конкретно в BTRFS и UEFI/GPT я новичок, ибо не доверял/не ковырял их пока, в остальном -- нет, причем в обороте масса разных Linux-систем и девайсов.

Разбивать пробовал и в MBR, и в GPT.

Ставил РОСУ разбивкой и автоматом, и вручную. После автоустановки (всё работает, но понятно ext4 и один винт) имеющиеся разделы / и swap (который отдельно не нужен) сносил, объединял в один, форматировал командой выше (имена разделов поправил канеш) в BTRFS RAID1, ставил РОСУ поверх снова -- вроде всё прокатывает, но или GRUB не кажет куда ставит, или не находит потом раздел для продолжения загрузки.

Оставлять / под ext4 и выделять BTRFS только для /home нет резона -- не ускоряется собственно система, и кроме /home у меня есть ценные файлы и скрипты, которые нежелательно терять (уводить из RAID1).

Подскажите, please, рабочую схему разбивки для установки вручную, чтоб оно таки завелось -- разделы, их типы и флаги, точки монтирования и примерные размеры.
Без рабочего компа (LiveCD + старенький ноут рядом) уже поднапрягает экспериментировать... и если такая схема жизнеспособна -- подробное howto/wiki многим будет полезно.

[trs]

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

Зеркалирование данных (RAID1) подразумевает снижение скорости при записи. И с какого диска будет происходить чтение (медленного или быстрого) — не ясно.

Оставлять / под ext4 и выделять BTRFS только для /home нет резона

Так можно создать небольшой раздел для /boot, на том диске, что больше по объёму.

[Ansy]

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

Зеркалирование данных (RAID1) подразумевает снижение скорости при записи. И с какого диска будет происходить чтение (медленного или быстрого) — не ясно.

При записи это понятно, но

1. приоритет всё же на защите данных от выхода из строя одного из HDD, и
2. критичное по времени чтение у меня происходит чаще (загрузка программ, кэша браузеров), причем в параллель много файлов сразу -- тут должно помочь.

Оставлять / под ext4 и выделять BTRFS только для /home нет резона

Так можно создать небольшой раздел для /boot, на том диске, что больше по объёму.

Больший по объему HDD

1. не так исходно надежен, как меньший по объёму, и
2. /boot загружается редко (раз в неделю и реже), в отличие системы и программ -- готов потерпеть.

Но это всё теория -- на данный момент более интересен рабочий вариант разбивки, тогда и протестируем.

[trs]

Раздел /boot в ext4 (либо fat для uefi) нужен для установки на него GRUB и ядра.

[Ansy]

Раздел /boot в ext4 (либо fat для uefi) нужен для установки на него GRUB и ядра.

Однако, в автоматическом режиме UEFI-инсталлятор указывает точку монтирования этого раздела по-другому -- /boot/efi
Это я попробовал уже. На чистом неразмеченном первом HDD, предварительно удалив gparted-ом все разделы, таблица была в GPT.

Пока же констатируем -- в режиме UEFI/GPT загрузочный раздел должен быть FAT32 размером ~255МБ, с флагами boot,esp и монтироваться в /boot/efi
Попробую удалить остальные разделы и создать на их месте общий BTRFS с монтированием в / пока без RAID и subvolumes.

Для истории и сравнения -- скорости доступа к HDD:

# hdparm -tT /dev/sd[ab]
/dev/sda:
Timing cached reads: 9490 MB in 2.00 seconds = 4750.82 MB/sec
Timing buffered disk reads: 196 MB in 3.01 seconds = 65.07 MB/sec
/dev/sdb:
Timing cached reads: 9532 MB in 2.00 seconds = 4771.36 MB/sec
Timing buffered disk reads: 322 MB in 3.00 seconds = 107.18 MB/sec

А это в ноутбуке старом винт 5400rpm -- ну не позор ли так сливать ноуту?

# hdparm -tT /dev/sda
Timing cached reads: 968 MB in 2.00 seconds = 484.92 MB/sec
Timing buffered disk reads: 134 MB in 3.00 seconds = 44.63 MB/sec

[Ansy]

Итак, снёс три раздела (/dev/sda[234]), первый загрузочный не трогал, создал в полученном пустом месте раздел btrfs, отформатировал, смонтировал в /mnt, создал там subvolume /mnt/home.
Затем начал установку с ручной разбивкой, но там лишь назначил точки монтирования /boot/efi для имеющегося /dev/sda1 и / для созданного /dev/sda2 (который теперь btrfs с субтомом для хомяка).
Инсталлятор выдаёт такое предупреждение однако (поверх окно gparted с разбивкой наложил):

Далее выбираю установку, сняв галку с форматирования /dev/sda2.
И в процессе установки, в окошке УЖЕ НЕТУ даже ВЫБОРА РАЗДЕЛА для начального загрузчика:

Ну и на выходе ребутаемся, когда просят -- опаньки

Код: Выделить всё

GNU GRUB version 2.0
Minimal BASH-like line editing ...
grub> _

И чо делать-то?

[trs]

Раздел /boot в ext4 (либо fat для uefi) нужен для установки на него GRUB и ядра.

Однако, в автоматическом режиме UEFI-инсталлятор указывает точку монтирования этого раздела по-другому -- /boot/efi

Поскольку Вы сами пишете, что с UEFI ни разу не сталкивались, а MBR схема проще, я говорил о последнем варианте. Для UEFI может быть необходимо создать 2 раздела, /boot (ext4) и /boot/efi с параметрами что Вы сами нашли. У Вас же получается установить, когда корень не в BtrFS, а в ext4, и в этом случае каталог /boot как ни странно оказывается ext4. В /boot содержится ядро и компоненты GRUB, в частности btrfs.mod (необходим для чтения btrfs).

[Ansy]

Итак, мне удалась половина задачи.

1. Один из HDD /dev/sda очистил и gparted-ом создал таблицу разделов в MBR (было GPT). Но сами разделы не создавал!
2. Запустил (это всё из LiveCD ROSA.FRESH.KDE.R8.x86-64.uefi) установку автоматом. Но когда предложили перезагрузиться -- НЕ СТАЛ этого делать!
3. Зашел снова в gparted и убил все разделы кроме первого /dev/sda1 /boot (удаляем swap /dev/sda5, рутовый /dev/sda6, в т.ч. и содержащий их extended /dev/sda2).
4. Создал на свободном месте новый основной раздел /dev/sda2 типа btrfs, отформатировал даже его под btrfs (не факт, что надо на этом этапе, но для будущего попробовал).
5. Запустил заново инсталлятор. На этот раз в режиме использования существующих разделов.
6. Точки монтирования указал первому /dev/sda1 -- /boot (который не трогал), новому второму btrfs-ному -- / (рут то бишь, для всей системы целиком). Субтома пока не пробовал создавать.
7. Загрузчик GRUB2 очевидно указываем на MBR диска в целом (/dev/sda).
8. Ставимся, перегружаемся -- взлетело!

Спасибо за полезные советы, теперь будем пробовать на двух HDD сообразить корень в виде btrfs-ного RAID1.

[trs]

Обычная файловая система может быть отзеркалирована путем добавления нового устройства с последующей балансировкой.
Наример, что бы конвертировать существующий одиночный раздел /dev/sdb1 в RAID1 (для защиты от отказа одного из дисков):

Код: Выделить всё

mount /dev/sdb1 /mnt
btrfs device add /dev/sdc1 /mnt
btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt

https://btrfs.wiki.kernel.org/index.php ... Conversion

Как я понимаю, sdb1 из примера нужно заменить на sda2, а sdc1 на sdb2, предварительно разметив начало второго (бо́льшего по размеру) накопителя аналогично первому, а его остаток как угодно.

[Yamah]

Итак, мне удалась половина задачи.

У меня и MBR и UEFI работают с таблицей GPT.
Создавал в консоли. Предположим, наш диск будет /dev/sda
0. Вычищаем первые 16 МБ диска

Код: Выделить всё

dd if=/dev/zero of=dev/sdk bs=1M count=16

1. Запускаем gdisk

Код: Выделить всё

gdisk /dev/sda

дальше жмем кнопку "o" и соглашаемся на внесение изменений
1) Затем жмет кнопку "n" - это вызовет диалог создания нового раздела.
- Первым он запросит номер раздела. Можно согласится на по-умолчанию (жмем энтер), а можно ввести свой номер от 1 до 127 и нажать энтр.
- Потом он запросит начальный сектор. Выбираем по-умолчанию (жмем энтер).
- Потом он запросит последний сектор. Тут пишем "+2M", жмем энтер,
- Далее он спросит тип раздела. Выдаем ему "EF02".
2)Снова жмем n. И создаем раздел UEFI.
Первые два пункта по аналогии.
- Запрос конечного сектора. Отвечаем +32M (для одной Росы заглаза. Хватит еще штук пять Линуксов поставить.). Если еще и виндец будет жить, то ответить +100M
- Тип раздела EF00
3) Жмем n. Создаем раздел подкачки.
Конечный сектор +16GB (тут нужно использовать двойной размер от оперативы, чтобы нормально использовать гипернейт).
Тип раздела 8200
Если планируется BTRFS использовать без сжатия, то можно создать только его. Если планируется использовать сжатие, то нужен раздел boot.
4) создаем boot. жмем n
Конечный сектор +1GB (можно и 256M, но тогда без снапшотов придется жить)
Тип раздела по умолчанию.
5). Создаем корневой раздел. На все вопросы жмем по умолчанию, если больше разделов не будет, иначе выбрать нужный объем.
6) жмем "w" и соглашаемся применить изменения. Возможно потребуется перезагрузка.
2. Форматируем разделы
Допустим нумерация разделов была по умолчанию.
1). EFI

Код: Выделить всё

mkfs.vfat -n EFI_BOOT /dev/sda2

2) SWAP

Код: Выделить всё

mkswap -L Swap /dev/sda3

3) Boot

Код: Выделить всё

mkfs.btrfs -L Boot -f /dev/sda4

4). System

Код: Выделить всё

mkfs.btrfs -L "Linux" -f /dev/sda5

3.создаем подтома

Код: Выделить всё

mount /dev/sda4 /media
btrfs subvolume create /media/@Rosa_Fresh_2014.1
umount /media
mount /dev/sda5 /media
btrfs subvolume create /media/@Rosa_Fresh_2014.1_KDE
umount /media

Если будет BTRFS без сжатия, то раздела /boot отдельного не будет.

4. Установка
Запускается с образа с UEFI.
Все как обычно. Только для / жмется "экспертные настройки" (или что-то типа этого). В опциях монтирования дополнительно прописывается "compress=lzo,subvol=@Rosa_Fresh_2014.1_KDE", для boot аналогично: "subvol=@Rosa_Fresh_2014.1". Разделу с UEFI, достается точка монтирования /boot/efi

[Ansy]

Интересный момент хочу прояснить:

На самой BTRFS делать swap проблематично, насколько нагуглил -- по разным архитектурным причинам, не суть.
Отдельный раздел под swap отводить я тоже не люблю -- он мало используется постоянно, хотя ИНОГДА, ОЧЕНЬ РЕДКО туда что-то влезает от больших процессов, чтобы не упасть всей системе.
Насчет гибернации так вообще пока не в курсе, куда и как в Линуксе она делается, не надобилось пока (вот думаю, что ж ноут не гибернуется? А у него swap файлом на подмонтированном виндовом NTFS...)

Но! У нас же /boot же не всегда работает, а только при загрузке? Как и /boot/EFI впрочем.
И форматирование у них простейшее -- FAT или EXT2/3 (разве BTRFS тут имеет какие-то преимущества?)
Так можно ли один из этих разделов создать заведомо побольше, и разместить там swap не разделом, а файлом?
Что мы теряем из функционала в таком случае? Зато при нужде можно убавить swap или вообще использовать это место для бэкапа или переноса файлов при манипуляциях с разделами.

Опять же, в продолжение -- что мешает нам для /boot скроить на двух HDD массив RAID0 (особо ценной инфы там же нет?) средствами mdadm -- это ускорит И загрузку, И swap?
А уж корень системы, хомяки и прочее -- как планировалось, в BTRFS и RAID1 на несколько HDD тоже средствами BTRFS.

Или я чего-то существенно важного не догоняю по дилетантству своему?

[trs]

Если увеличить раздел boot, с точки зрения оставшегося места это будет выглядеть равносильно созданию отдельного раздела (который по необходимости можно переформатировать и использовать для бэкапа или переноса файлов). К тому же, gparted позволяет менять размер ext разделов. 2 swap раздела на разных дисках должны работать подобно RAID0, если не ошибаюсь.

С boot раздела на RAID0 запустить систему можно в случае если он аппаратный (хотя бы fake-raid), но к заметного ускорения это не даст, поскольку основной объём данных читается с корневого каталога.

Кстати, на ZFS можно создавать подкачку (в т.ч. со сжатием), по-видимому, в силу отсутствия таких архитектурных причин, как в BtrFS.

[Yamah]

2 swap раздела на разных дисках должны работать подобно RAID0, если не ошибаюсь.

Не совсем верно. Ядро будет балансировать нагрузку на своп-раздел. То есть, данные первого процесса будут свопиться на первый раздел, данные второго на второй.

С boot раздела на RAID0 запустить систему можно в случае если он аппаратный (хотя бы fake-raid), но к заметного ускорения это не даст, поскольку основной объём данных читается с корневого каталога.

Кстати, на ZFS можно создавать подкачку (в т.ч. со сжатием), по-видимому, в силу отсутствия таких архитектурных причин, как в BtrFS.[/quote]

[Ansy]

Итак, мне удалась половина задачи.

У меня и MBR и UEFI работают с таблицей GPT.
Создавал в консоли. Предположим, наш диск будет /dev/sda
0. Вычищаем первые 16 МБ диска
...

Поскольку выпустили свежую сборку 8.1, и подвернулись выходные -- на свободный HDD рабочего компа, не мудрствуя лукаво, решил накатить всё до буквы по любезно вышеприведённой инструкции -- дабы и её проверить, и новый дистрибутив с другим ядром на своём железе протестировать, и кое-какие свои соображения уточнить на чистой системе.

Ну, в общем, взлетело оно нормуль. Вроде как живёт, драйвера на nVidia проприетарные подоткнулись, FF синхронизировался, с сеткой проблем не возникло (в одном из прошлых дистрибов драйвер сетевухи не работал). Можно ставить в качестве рабочей системы "на каждый день".
Проба здесь https://linux-hardware.org/index.php?probe=4bd17e4165

По инструкции установки. Понимаю, что она примерная, и специально не обкатывалась, но всё же, поскольку ПРАКТИЧЕСКИ рабочая -- может многим пригодиться в качестве пошагового HOWTO.
Поэтому было бы замечательно уточнить моменты с инсталлятором, которые походу недостаточно конкретизированы, и потому возможны косяки, которые у меня, в частности, фатально не убили инсталляцию, но таки вылезли.

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

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

1. /dev/sda1 с grub ругается на отсутствие файловой системы (возможно, и не проблема, с gpt не работал раньше вплотную, на mbr/msdos такого не встречал, но глаз мозолит).
2. /dev/sda4 никуда не смонтировано. Может, пропустил сам -- надо в /boot? Инструкция "неразборчиво"... Не фатально пока, наверное можно позже накопать UUID, добавить в /etc/fstab, а контент /boot (без efi) скопировать в subvol, подмонтировав /dev/sda4 в /mnt например. Но я таки планирую повторить процедуру повторно, вчистую. Если есть поправки в инструкцию, прошу дополнить, пока тестируется.
3. subvol для /dev/sda4 точно прописывал, однако без указания точки монтирования он наверное и не зацепился в /etc/fstab, и не сработал.

В дальнейшем планирую:

• Протестировать гибернацию (на swap место выделил).
• После подключения второго HDD закатать /home в зеркало добавлением устройства в BTRFS.
• И остаток места на втором HDD выделить под NTFS для параллельной Винды -- в VirtualBox, но на "железном" разделе -- для бэкапа, межплатформенного обмена и вытаскивания критичных данных, если BTRFS вдруг фатально откажет.

P.S. Модификация /etc/fstab и копирование файлов /boot (с обновлением grub) прошло успешно, проба здесь https://linux-hardware.org/index.php?probe=bbe37a344f
P.P.S. Гибернация тоже работает Но вот не нашёл менюшку, раздел "Завершения работы" или экранной кнопки/виджета для её запуска. Пришлось повесить на кнопку питания (действие "Спящий режим").
P.P.P.S. Вчистую форматнул все разделы, накатил систему уже с монтированием /dev/sda4 в /boot -- всё прошло идеально.
Ошибку /dev/sda1 тоже устранил -- форматнул раздельчик в ext2, ибо из-за мелкого размера он ни в FAT16, ни в FAT32 (через GParted) форматироваться не хотел.

[Yamah]

Ansy
У меня по этой инструкции установлены на дюжине ПК Rosa Fresh (не считая ПК, где я вынужден был ставить Fedora, OpenSUSE, Debian) и на 5 флэшках MagOS. Я не ожидал, что нужно будет на форуме расписывать в деталях сам процесс установки. Это не для WIKI.

1. Первый раздел нужен для работы BIOS Legacy. Там не должно быть ФС. И устанавливать груб туда не надо. Так же не надо его монтировать.
2. Разумеется, раздел с меткой "Linux", должен быть смонтирован на /, а раздел с меткой "Boot" на /boot, а еще раздел с меткой "EFI_BOOT" на /boot/efi
3. Опция subvol естественно сработает только для прописанного в fstab раздела.

Я бы посоветовал использовать хотя бы fake-raid и AUFS. Во-первых, это повышает производительность системы, так как процессы записи на raid-btrfs жрут больше ресурсов, чем fake-raid и AUFS. Домашний каталог у меня как раз так и смонтирован: на объединенных в fake-raid-1 двух HDD на 2 GB и подтома на полтора GB на системном SSD. В итоге система грузится за 5 секунд до приглашения KDM от начала загрузки ядра и 5 секунд до рабочего стола с авторизации пользователя.

[Ansy]

Я не ожидал, что нужно будет на форуме расписывать в деталях сам процесс установки. Это не для WIKI.

Ну почему же не для Wiki... проблема-то с инструкцией была лишь в том, что процедура действий в ИНСТАЛЛЯТОРЕ указана лишь намеками -- а вариантов "прохождения квеста" там намного больше, и много есть где напутать. Если это разжевать более подробно (а то ещё и с парой скриншотов) -- была бы вполне рабочая HOWTO-шка для Wiki. Учитывая, что не так мало пользователей Linux ставят системы на далеко не новое оборудование, не с самыми надежными и скоростными винтами, не всегда одинаковых (для RAID-1) размеров. А преимущество перед Windows как раз получается внушительное.

1. Первый раздел нужен для работы BIOS Legacy. Там не должно быть ФС. И устанавливать груб туда не надо. Так же не надо его монтировать.

То есть высвечивание ошибки, восклицательного знака gparted-ом считаем нормальной ситуацией? http://forum.rosalab.ru/download/file.p ... &mode=view

3. Опция subvol естественно сработает только для прописанного в fstab раздела.

Ну вот, я наверное забыл в монтирование добавить, поэтому всё остальные опции для этого раздела и не применились. Ладно, не фатально, поправил руками потом.

Я бы посоветовал использовать хотя бы fake-raid и AUFS. Во-первых, это повышает производительность системы, так как процессы записи на raid-btrfs жрут больше ресурсов, чем fake-raid и AUFS. Домашний каталог у меня как раз так и смонтирован: на объединенных в fake-raid-1 двух HDD на 2 GB и подтома на полтора GB на системном SSD. В итоге система грузится за 5 секунд до приглашения KDM от начала загрузки ядра и 5 секунд до рабочего стола с авторизации пользователя.

Если под fake-raid-1 подразумевается использование встроенного в материнку адаптера, то этот вариант не катит, ибо:

1. Материнка может сдохнуть вместе с контроллером, что уже было пару раз на моей памяти, и от Винды оставались лишь незагружабельные винты с данными, безотносительно к RAID это потеря многих часов рабочего времени на восстановление рабочей среды.
2. У меня нет ОДИНАКОВОЙ ЁМКОСТИ дисков для поднятия RAID-1 на железном/fake контроллере, равно как и нет желания терять доступное место на бОльшем из дисков. Это не сервер, это повседневная рабочая станция, и контора очень неохотно идёт на железячные апгрейды -- об SSD даже не мечтаем, пользуем то, что есть. Один винт надёжный, но маловат и медленноват, второй шустрый и вдвое больше, но из рассыпавшегося ранее RAID-а в сервере начального уровня, уже имеет наработку и некоторое количество стабильных бэдблоков в хвосте.
3. Я могу накатить Linux на любую другую материнку взамен (если вдруг) сдохшей (в отличие от Windows) или даже поработать какое-то время с Live-носителя -- если будет возможность примонтировать ЛЮБОЙ из этой пары дисков с данными, BTRFS-RAID1 такое позволяет, в отличие от fake-raid.
4. С потерей информации на бОльшем (быстром, но не столь надёжном) диске готов смириться, ибо останется "зеркало" на мелком/надёжном, а в "хвосте" пространства, оставленного от RAID-1, размещена NTFS для межплатформных экспериментов, (бэкапируемых в сеть) виртуалок (ибо основной BTRFS-RAID1 со сжатием, они этого не любят) и некритичного тяжелого контента (временные файлы, сливы данных с восстанавливаемых носителей, дистрибутивы, доступные из Сети, видеофайлы наблюдения и т.п.)
5. Процессорная мощность -- дело последнее, ибо у меня конкретно камушек абсолютно некритичное место, как наверное и у большинства пользователей ПК. Обработка обмена с диском и сжатие абсолютно не напрягают.

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

P.S. Вот кстати еще один возможный косячок. Почему ДВОЙНОЕ монтирование рутового раздела /dev/sda5 при указанном ниже содержимом /etc/fstab ?

master@Black ~ $ mount | grep /dev/sd
/dev/sda5 on / type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@Rosa_Fresh_2014.1_KDE)
/dev/sda4 on /boot type btrfs (rw,relatime,space_cache,subvolid=256,subvol=/@Rosa_Fresh_2014.1)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda5 on /media/master/Linux type btrfs (rw,nosuid,nodev,relatime,compress=lzo,space_cache,subvolid=5,subvol=/)
/dev/sdb2 on /media/master/5C8138A75C4E07E7 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

master@Black ~ $ cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
#Entry for /dev/sdb1 :
UUID=3b1a8616-586e-4475-8e92-756eb3c8d122 / btrfs compress=lzo,relatime,nofail,subvol=@Rosa_Fresh_2014.1_KDE 1 1
#Entry for /dev/sda4 :
UUID=e6a1254e-8e02-4c12-912d-065bfbb855d9 /boot btrfs subvol=@Rosa_Fresh_2014.1,relatime,nofail 1 2
#Entry for /dev/sda2 :
UUID=F046-A1EC /boot/efi vfat umask=0,nofail 0 0
#Entry for /dev/sdb2 :
UUID=5C8138A75C4E07E7 /media/master/5C8138A75C4E07E7 ntfs-3g defaults,nodev,nosuid,locale=ru_RU.UTF-8 0 0
none /proc proc defaults 0 0
#Entry for /dev/sda3 :
UUID=a368c915-f012-4a86-b570-7b8516125dc2 swap swap nofail 0 0

[Yamah]

Ну почему же не для Wiki... проблема-то с инструкцией была лишь в том, что процедура действий в ИНСТАЛЛЯТОРЕ указана лишь намеками -- а вариантов "прохождения квеста" там намного больше, и много есть где напутать. Если это разжевать более подробно (а то ещё и с парой скриншотов) -- была бы вполне рабочая HOWTO-шка для Wiki.
Не для Wiki потому, что у меня не было желания делать викифицированную статью. Мой пост в помощь уже продвинутым юзерам, кто захотел словить еще больше вкусняшек от системы.

То есть высвечивание ошибки, восклицательного знака gparted-ом считаем нормальной ситуацией? http://forum.rosalab.ru/download/file.p ... &mode=view

Естественно. Jн не видит никакой файловой системы. Значит пользователя надо предупредить, что там что-то не так.

Если под fake-raid-1 подразумевается использование встроенного в материнку адаптера, то этот вариант не катит, ибо:

1. Материнка может сдохнуть вместе с контроллером, что уже было пару раз на моей памяти, и от Винды оставались лишь незагружабельные винты с данными, безотносительно к RAID это потеря многих часов рабочего времени на восстановление рабочей среды.

В 2014 году я спокойно перенс диски в Fake-Raid-1 с Asus Crosshair M2 (nForce), на Asus Crosshair V Formula-Z (AMD), контроллер на новой материнки их подхватил как родные автоматом. Я даже офигел от такого сервиса.

[*]Я могу накатить Linux на любую другую материнку взамен (если вдруг) сдохшей (в отличие от Windows) или даже поработать какое-то время с Live-носителя -- если будет возможность примонтировать ЛЮБОЙ из этой пары дисков с данными, BTRFS-RAID1 такое позволяет, в отличие от fake-raid.

Диски fake-raid-1 можно безболезненно читать и без raid-контроллера по одному. А вот писать на них не надо чтобы не сломать симметрию данных.

[*]С потерей информации на бОльшем (быстром, но не столь надёжном) диске готов смириться, ибо останется "зеркало" на мелком/надёжном, а в "хвосте" пространства, оставленного от RAID-1, размещена NTFS для межплатформных экспериментов, (бэкапируемых в сеть) виртуалок (ибо основной BTRFS-RAID1 со сжатием, они этого не любят) и некритичного тяжелого контента (временные файлы, сливы данных с восстанавливаемых носителей, дистрибутивы, доступные из Сети, видеофайлы наблюдения и т.п.)

При условиях, что умрет винт, а не винт+ФС. Я такое не так давно пережил - данные целые, а вот метаданные, журналы и блоки со структурой ФС накрылись медным тазом. Спасло только, что данные можно было восстановить (медленно и ни разу неинтерактивно на другой носитель) встроенным функционалом. Восстановление 1 Терабайта у меня заняло 4 суток. А вся проблема в том, что на диске помирал контроллер (а не бэдблоки появились), и из-за его глюков в каой-то момент ядро переписало область метаданных на нормальном диске. Fake-raid изначально бы пометил сбойный диск, и не допустил бы такой фейла ядра.
И да, вы получите скорость работы медленного винта как на запись, так и на чтение. Ибо система будит читать сектора попеременно с разных дисков.
В вашем же случая я бы просто rsync-ом синхронизовывал данные при изменениях на одном диске. (Всего-то нужен скрипт, который будет создавать снапшоты на время синхронизации, монтировать из и синхронизировать со вторым диском, при наступления событий изменения на ФС.)

[*]Процессорная мощность -- дело последнее, ибо у меня конкретно камушек абсолютно некритичное место, как наверное и у большинства пользователей ПК. Обработка обмена с диском и сжатие абсолютно не напрягают.[/list]

Ну это где как. На довольно загруженных машинах (СУБД, конвертация видео, 1С) - это может вызвать солидную потерю в производительности.

P.S. Вот кстати еще один возможный косячок. Почему ДВОЙНОЕ монтирование рутового раздела /dev/sda5 при указанном ниже содержимом /etc/fstab ?

Потому, что у вас разные подтома. А с учетом того, что второй раз у вас смонтировалось в /media//master, то я делаю вывод (а мог бы провести сеанс ясновидения ), что ваш логин master, а смонтировалось туда потому, что вы в дельфине кликнули по диску с системным подтомом.

Монтировать подтома на одном разделе можно

Код: Выделить всё

mount | grep sdc3
/dev/sdc3 on / type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=374,subvol=/@Rosa_Fresh_2014.1_KDE4)
/dev/sdc3 on /usr/local type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=263,subvol=/Common/USR_Local)
/dev/sdc3 on /opt type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=262,subvol=/Common/OPT)

cat /etc/fstab | grep subvol
UUID=d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 / btrfs noatime,nofail,subvol=@Rosa_Fresh_2014.1_KDE4,compress=lzo 1 1
UUID=d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 /opt btrfs noatime,nofail,subvol=Common/OPT,compress=lzo 1 1
UUID=d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 /usr/local btrfs noatime,nofail,subvol=Common/USR_Local,compress=lzo 1 1
/dev/sda /home btrfs subvol=@Rosa_Fresh_Home,compress=lzo 1 1
/dev/sda /mnt/Zone/Home/Old btrfs subvol=Home,compress=lzo 1 1
/dev/sda /mnt/Zone/Home/Common btrfs subvol=@Common,compress=lzo 1 1
/dev/sda /mnt/Zone/Home/Cache btrfs subvol=@Cache,compress=lzo 1 1

[Ansy]

Диски fake-raid-1 можно безболезненно читать и без raid-контроллера по одному. А вот писать на них не надо чтобы не сломать симметрию данных.

Ну вот, именно потому, что мне ПРИДЕТСЯ РАБОТАТЬ на одном из HDD деградировавшего массива какое-то время -- надо иметь возможность записи на него. А потом опять расширить в зеркало -- уже на тот HDD, что появится для замены -- и опять не факт, что даже похожего размера и скорости. Эдакое ползучее апгрейдо-зеркальное хранилище /home. Ну и до кучи, по возможности, загрузочное.

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

Может быть я что-то не так понял в BTRFS с режимом RAID-1? Странно, хотя бы РАЗНЫЕ файлы оно должно при параллельном чтении тащить с РАЗНЫХ шпинделей... а это IMHO несколько шустрее, чем ждать прыжка головок + вращение до нужного сектора на ОДНОМ шпинделе. Или алгоритмы распараллеливания чтения RAID-1 в BTRFS настолько тупее, чем в mdadm/dmraid/fake-raid/hardware-raid ?

Чесговоря, этот вопрос требует экспериментальной проверки. Чем измерить, не сильно навороченным? Результаты отдельно для шпинделей выдаёт hdparm -tT /dev/sd[ab], для файловой системы есть что-то сопоставимое алгоритмически? Да, у нас же ещё и сжатие в BTRFS -- но только на одном разделе, так что есть где сравнить.

P.S. Вот кстати еще один возможный косячок. Почему ДВОЙНОЕ монтирование рутового раздела /dev/sda5 при указанном ниже содержимом /etc/fstab ?

Потому, что у вас разные подтома. А с учетом того, что второй раз у вас смонтировалось в /media//master, то я делаю вывод (а мог бы провести сеанс ясновидения ), что ваш логин master, а смонтировалось туда потому, что вы в дельфине кликнули по диску с системным подтомом.

Сеанс ясновидения канеш в точку Действительно, кликал и неоднократно, и оно где-то сохранилось. Ну, не напрягает, и надо в принципе практически постоянно -- лишь бы не глючило.

[Yamah]

Может быть я что-то не так понял в BTRFS с режимом RAID-1? Странно, хотя бы РАЗНЫЕ файлы оно должно при параллельном чтении тащить с РАЗНЫХ шпинделей... а это IMHO несколько шустрее, чем ждать прыжка головок + вращение до нужного сектора на ОДНОМ шпинделе. Или алгоритмы распараллеливания чтения RAID-1 в BTRFS настолько тупее, чем в mdadm/dmraid/fake-raid/hardware-raid ?

Во всех трех случаях чтение идет не по файлам, а по блокам диска. Это описывается ф спецификации уровня raid.

dmraid - это механизм ядра Linux работать fake-raid.

Чесговоря, этот вопрос требует экспериментальной проверки. Чем измерить, не сильно навороченным? Результаты отдельно для шпинделей выдаёт hdparm -tT /dev/sd[ab], для файловой системы есть что-то сопоставимое алгоритмически? Да, у нас же ещё и сжатие в BTRFS -- но только на одном разделе, так что есть где сравнить.

dd - же. Записать на диск большой файл и считать его dd-шкой в /dev/null.

[Ansy]

Может быть я что-то не так понял в BTRFS с режимом RAID-1? Странно, хотя бы РАЗНЫЕ файлы оно должно при параллельном чтении тащить с РАЗНЫХ шпинделей... а это IMHO несколько шустрее, чем ждать прыжка головок + вращение до нужного сектора на ОДНОМ шпинделе. Или алгоритмы распараллеливания чтения RAID-1 в BTRFS настолько тупее, чем в mdadm/dmraid/fake-raid/hardware-raid ?

Во всех трех случаях чтение идет не по файлам, а по блокам диска. Это описывается ф спецификации уровня raid.

dmraid - это механизм ядра Linux работать fake-raid.

Чесговоря, этот вопрос требует экспериментальной проверки. Чем измерить, не сильно навороченным? Результаты отдельно для шпинделей выдаёт hdparm -tT /dev/sd[ab], для файловой системы есть что-то сопоставимое алгоритмически? Да, у нас же ещё и сжатие в BTRFS -- но только на одном разделе, так что есть где сравнить.

dd - же. Записать на диск большой файл и считать его dd-шкой в /dev/null.

Точно же! У dd в выводе есть средняя скорость передачи. Поехали:

master@Black ~ $ fdisk -l /dev/sd[ab]

Код: Выделить всё

Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectors
Disklabel type: gpt
Device        Start       End   Sectors   Size Type
/dev/sda1      2048      6143      4096     2M BIOS boot
/dev/sda2      6144    210943    204800   100M EFI System
/dev/sda3    210944  33765375  33554432    16G Linux swap
/dev/sda4  33765376  35862527   2097152     1G Linux filesystem
/dev/sda5  35862528 488397134 452534607 215,8G Linux filesystem

Disk /dev/sdb: 464,3 GiB, 498571862528 bytes, 973773169 sectors
Disklabel type: dos
Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1            2048 452536319 452534272 215,8G 83 Linux
/dev/sdb2       452536320 973773168 521236849 248,6G  7 HPFS/NTFS/exFAT

master@Black ~ $ mount | grep /dev/sd

# Основной BTRFS RAID-1 из разделов /dev/sda5 и /dev/sdb1
/dev/sda5 on / type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@Rosa_Fresh_2014.1_KDE)
# Загрузочный раздел BTRFS без сжатия, снапшотов пока нет, объем небольшой, файлы мелковаты
/dev/sda4 on /boot type btrfs (rw,relatime,space_cache,subvolid=256,subvol=/@Rosa_Fresh_2014.1)
# EFI boot
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
# Это "хвост" второго, шустрого, ну уже покоцанного HDD, сформатировано в NTFS для виртуалок и переноса данных
/dev/sdb2 on /media/master/5C8138A75C4E07E7 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

master@Black ~ $ df | grep -v tmp

Код: Выделить всё

Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sda5          216G          39G  177G           19% /
/dev/sda4          1,0G         104M  819M           12% /boot
/dev/sdb2          249G          18G  231G            8% /media/master/5C8138A75C4E07E7

master@Black ~ $ hdparm -tT /dev/sd[ab]
/dev/sda:
Timing cached reads: 8748 MB in 2.00 seconds = 4379.55 MB/sec
Timing buffered disk reads: 216 MB in 3.02 seconds = 71.48 MB/sec
# Это с блинов первого физического медленного надежного HDD

/dev/sdb:
Timing cached reads: 8876 MB in 2.00 seconds = 4443.13 MB/sec
Timing buffered disk reads: 312 MB in 3.02 seconds = 103.45 MB/sec
# Это с блинов второго винта пошустрее, но уже с бэд-блоками в хвосте

# Читаем с /boot-раздела, BTRFS без сжатия на первом медленном винте
Black boot # dd if=initrd-4.9.9-nrj-desktop-1rosa-x86_64_old.img of=/dev/null
скопирован 15482641 байт (15 MB), 0,242468 c, 63,9 MB/c
# -- скорость вполне ожидаемая

# читаем с хвоста второго шустрого диска
master@Black ~ $ dd if=/media/master/5C8138A75C4E07E7/AnotherBigFile.zip of=/dev/null
скопировано 1328961774 байта (1,3 GB), 20,8885 c, 63,6 MB/c
# -- учитывая NTFS и FUSE -- замедление ожидаемое, хотя винт и побыстрее

# Читаем с основного BTRFS RAID-1 со сжатием
master@Black ~ $ dd if=/home/master/BigFile.zip of=/dev/null
скопировано 5314224734 байта (5,3 GB), 51,2404 c, 104 MB/c
# -- а вот тут явно шустрее, чем с первого медленного HDD -- или сжатие, или поток с более быстрого шпинделя

Так что получается не самый медленный из возможных вариантов, чем я вполне доволен.

[Ansy]

Други мои, после штудирования темы NAS по профильным форумам и площадкам опять возник зуд на странное... итак, задача:

1. Имеем 2 (два) HDD различной ёмкости.
2. Надо один каталог повышенной надёжности (mirror на два HDD) -- для критичных данных -- проекты, архив личных фото, переписка, документы, явки-пароли и т.п.. + возможно сжатие на лету.
3. Надо второй каталог НЕкритичной надежности -- объемные дистрибутивы, фильмы, временные бэкапы, прошивки -- что не так сложно нарыть в Инете заново, и сжимать их смысла не имеет кстати.
4. Главное -- весь дисковый объем под эти два каталога должен прозрачно, динамически выделяться под файлы из общей системы хранения, ибо заранее неизвестно, сколько места надо под надёжную часть, а сколь оставить под трэш.
5. При отказе одного из HDD файлы первого зеркалируемого каталога должны читаться, на содержимое второго чихать... хотя желательно канеш, чтоб уцелевшие файлы тоже прочлись.

Внимание, вопрос!
Существует ли решение средствами BTRFS или хотя бы ZFS?
Ну, чтоб использовать subvolumes с необходимыми параметрами?

[Vochatrak]

Господа, помогите с проблемой.
Не могу перейти из снапшота в другой снапшот.
В нолевом томе есть 3 снапшота

Код: Выделить всё

btrfs subvolume list /
ID 267 gen 29075 top level 5 path snapshots/compil
ID 276 gen 28992 top level 5 path @do
ID 278 gen 28995 top level 5 path @courent

Нахожусь сейчас в snapshots/compil
Вбиваю

Код: Выделить всё

btrfs subvolume set-default 278 / 

После перезагрузки ничего не меняется.

[trs]

В некоторых случаях следует сгенерировать новый initrd

Код: Выделить всё

dracut -f

на всякий случай можно создать универсальный вариант (большой по объёму файл со всеми драйверами)

Код: Выделить всё

dracut -f -N

а после перезапуска выполнить первую команду.

[Vochatrak]

Проблема была в grub.cfg.
Почему-то update-grub2, упорно вписывает rootflags=subvol.
Только в этот раз, почему-то использовался конфиг НЕ из того снапшота, в котором я находился.
Как бы заставить систему, генерить правильный grub.cfg?
Без указания субволюмов и полных путей относительно нулевого тома...

[Yamah]

Так! Grub на отдельном разделе или в том же томе BTRFS?

А вообще я не мучаюсь. Снапшоты я меняю так:

Код: Выделить всё

btrfs subvolume snapshot $MainSubvolume $newSnapshot
btrfs subvolume delete $MainSubvolume
btrfs subvolume snapshot $otherSnapshot $MainSubvolume

[Vochatrak]

Так! Grub на отдельном разделе или в том же томе BTRFS?

В mbr надо пологать.
Я изначально ставился в нолевой томм. Снапшот был в корне.
Теперь я перешел в снапшот и удалил систему из нолевого раздела.
В итоге, в нолевом томе лежит несколько снапшотов/субволюмов.
Переносится ли граб при снимке, я не знаю...

[Yamah]

В MBR или EFI может быть только минимальная часть загрузчика GRUB2. Все остальное располагается в в каталоге /boot/grub2
Сейчас у вас минимальная часть GRUBа ищит свои модули и конфиги в корневом томе, где естественно их уже нет. Вам нужно переустановить grub.

[Vochatrak]

Вам нужно переустановить grub.

А как собственно установить Граб в субволюм?
Установщик требует указать устройство.

[Yamah]

Итак имеем. Том с системой скажем @Rosa_Fresh_2016.1 на диске, скажем /dev/sda1, раздел подкачки на //dev/sda2 и, скажем, слетевший GRUB.
1. Грузимся с флешки с любым живым дистрибутивом Linux. Понятное дело, я рекомендую Rosa Fresh R9 или MagOS.
2. Монтируем разделы и необходимые каталоги и включаем подкачку

Код: Выделить всё

mount -o subvol=@Rosa_Fresh_2016.1 /dev/sda1 /media
mount -o bind /dev /media/dev
mount -o bind /sys /media/sys
mount -o bind /proc /media/proc
swapon /dev/sda2

3. черутимся в /media

Код: Выделить всё

chroot /media /bin/bash

4. Ставим GRUB2

Код: Выделить всё

grub2-install --no-floppy --root-directory=/ /dev/sda

Груб умеет искать необходимые ему файлы в подтомах. Главное, чтобы подтом не был сжатым.
Сделано.

[Vochatrak]

Главное, чтобы подтом не был сжатым.

А если он сжат?

[Yamah]

Главное, чтобы подтом не был сжатым.

А если он сжат?

А тогда /boot нужно выносить на отдельный раздел, который тоже нужно будет смонтировать в chroot-окружение до выполнения команды установки Grub.
Grub не умеет загружаться с сжатых томов. Зато умеет с подтомов.

[Vochatrak]

Главное, чтобы подтом не был сжатым.

Grub не умеет загружаться с сжатых томов. Зато умеет с подтомов.

Стоп, так все-таки ПОДтом или том не должны быть сжатыми?

[notauser]

http://gaijin-nippon.blogspot.ru/2011/06/lzo-btrfs.html

[Yamah]

Главное, чтобы подтом не был сжатым.

Grub не умеет загружаться с сжатых томов. Зато умеет с подтомов.

Стоп, так все-таки ПОДтом или том не должны быть сжатыми?

Если /boot находится на BTRFS разделе или его части (поддтоме), то раздел, или его чать не должны быть сжатыми. GRUB не умеет работать (искать модули, конфиги и грузить ядра) с ждатым разделом BTRFS
Если же /boot вынесен на внешний раздел (а это как правило extX, где X от 2 до 4), то GRUB-у уже все равно что там будет на других разделах. Он работает с extX разделом, а какие разделы будут дальше - это уже проблемы ядра, с точки зрения GRUB2.

[trs]

У BtrFS сжатие на уровне файлов. На одном разделе могут быть как сжатые, так и не сжатые. По ссылке notauser-а указано, как можно такого добиться. В случае нового диска, предполагаю, можно монтировать без compress=lzo, а задать сжатие для каталогов (кроме boot) при помощи chattr +c.

[Yamah]

У BtrFS сжатие на уровне файлов. На одном разделе могут быть как сжатые, так и не сжатые. По ссылке notauser-а указано, как можно такого добиться. В случае нового диска, предполагаю, можно монтировать без compress=lzo, а задать сжатие для каталогов (кроме boot) при помощи chattr +c.

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

[trs]

Точнее будет не для "остальных подтомов", а "для вновь создаваемых файлов на остальных подтомах". Если файл имелся на подтоме до монтирования, то его режим сжатия не меняется (пока файл не перезаписан). Таким образом можно монтировать (под)том со сжатием, но grub2 будет работать с несжатыми файлами на этом подтоме.

[Ansy]

Так может быть прицельно лишь несколько GRUB-файлов или каталог НЕ сжимать, атрибутами? А остальное по умолчанию в LZO? Не прокатит?

[mexx400]

К слову:

Компания Red Hat приняла решение не выводить Btrfs в разряд полностью поддерживаемых в RHEL технологий и поддержка данной ФС будет прекращена в будущем значительном выпуске RHEL 8 - http://www.opennet.ru/opennews/art.shtml?num=46955

[trs]

Так может быть прицельно лишь несколько GRUB-файлов или каталог НЕ сжимать, атрибутами? А остальное по умолчанию в LZO? Не прокатит?

На подобное решение и была дана ссылка http://forum.rosalab.ru/viewtopic.php?f ... 737#p87641

[Vochatrak]

Такс, тут такое дело...
Включаю baloo, эта штука сильно нагружает хард и через непродолжительное время, хомяк уходит в ro.
Ну ладно, гружусь с лайва btrfck показывает ошибки, btrfsck --repair чинит систему и больше не показывает ошибок.
Запускаю baloo и все повторяется вновь.
В общем либо Балу несовместим с btrfs, либо моей разметке хана, но btrfsck этого не видит.
Как можно полностью проверить btrfs?

[notauser]

Так и быть должно. Наверно.
baloo - а вот прямо сейчас я для Вас наделаю этих всяких индексов, а btrfs - да я и так уже устал(а), отстань. Файловая ситема дама капризная.
Применяемые Вами параметры btrfs позволят специалистам дать более развернутый ответ. Наверно.
Кстати, что там с загрузкой о которой Вы спрашивали?

[trs]

Есть ещё такая проверка

Код: Выделить всё

btrfs scrub start /dev/sda1

Запускается в фоне.
После чего смотрим

Код: Выделить всё

btrfs scrub status /dev/sda1

[Vochatrak]

Применяемые Вами параметры btrfs позволят специалистам дать более развернутый ответ. Наверно.

Код: Выделить всё

/home btrfs relatime,nofail,autodefrag,,compress=lzo,space_cache 0 0

Кстати, что там с загрузкой о которой Вы спрашивали?

Да пока ничего, собственно. Тут с глюками сначала разобраться бы надо...

btrfs scrub start /dev/sda1

Код: Выделить всё

btrfs scrub status /dev/sdb5
scrub status for 5ac71128-6fc5-4373-a491-082ae0753da3
        scrub started at Sun Sep  3 00:41:24 2017 and finished after 00:19:48
        total bytes scrubbed: 72.94GiB with 0 errors

И ведь главное, вчера опять повторилось. На ровном месте, хомяк ушел в РО.
Все тесты (включая whdd) говорят что проблем нет. Откатился на ядро 4.9.х (раньше было 4.11.х), может там какие проблемы.

P.S. Кстати, а вообще нужно через btrfs property set врубать сжатие разделу, если в фстабе compress=lzo? Просто btrfs property get не показывает что сжатие включено

[Yamah]

Проверить есть ли сжатие поможет утилиты du и df. Первая покажет размер файлов на диске, вторая информацию о занимаемом файлами месте. Результат df должен быть меньше.

Код: Выделить всё

cat /etc/fstab | grep opt
UUID=2a07d237-6fd5-4fb6-9a48-d7121c9fdb02 /opt btrfs subvol=OPT,compress=lzo 1 2

du -h /opt
<кусь>
58G     /opt

df -h | grep opt
/dev/sdb2                   101G          48G   52G           49% /opt

[Vochatrak]

Проверить есть ли сжатие поможет утилиты du и df.

Спасибо, вроде жмет.
Меня все-таки мущает наличие btrfs property set compress=lzo. Если все работает и без нее, зачем она нужна?

Кстати, переустановил граб по Вашей инструкции, спасибо.
Только в нее стоит добавить, что нужно перед установкой граба выполнить:

Код: Выделить всё

btrfs subvolume set-default 0 /диск на котором корень

И перезагрузиться.

[trs]

Меня все-таки мущает наличие btrfs property set compress=lzo. Если все работает и без нее, зачем она нужна?

А это точно есть? Хотелось бы увидеть пример использования.

Код: Выделить всё

# btrfs property get /
ro=false
label=r0

Код: Выделить всё

# btrfs property set / compress lzo 
ERROR: unknown property: compress

[Vochatrak]

А это точно есть? Хотелось бы увидеть пример использования.

Код: Выделить всё

btrfs property get /home
ro=false
label=home

Код: Выделить всё

btrfs property set /home compression lzo

Код: Выделить всё

btrfs property get /home
ro=false
label=home
compression=lzo

P.S. Где нарыл эту опцию не помню...

[Vochatrak]

Ну, вот опять.
Хомяк ушел в RO, но...

Код: Выделить всё

btrfs property get /home
ro=false
label=home
compression=lzo

При этом, я не могу ничего удалить или создать в хомяке.
Иногда, после перезагрузки, btrfsck даже ошибок на томе не находит!
Что это вообще может быть?

Вот еще

Код: Выделить всё

# mount | grep /home
/dev/sdb5 on /home type btrfs (ro,relatime,compress=lzo,space_cache,autodefrag,subvolid=5,subvol=/)

[trs]

Спасибо, compression пропустил. Проверил: если такое свойство установить, то монтировать можно без опции compress=lzo и сжатие будет включено.

По поводу перевода подтома в режим "только чтение", а какая версия ядра? Всё же разработка BtrFS не завершена, исправления регулярно вносят.

[Vochatrak]

По поводу перевода подтома в режим "только чтение", а какая версия ядра?

Код: Выделить всё

4.11.12-nrj-desktop-1rosa-x86_64 #1 SMP PREEMPT Fri Jul 21 11:34:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

По совету "откопанному" на каком-то форуме, удалил спейскеш и провел балансеровку, пока работает нормально.

[Vochatrak]

Такс, чего-то не того, вы мне насоветовали.
После переустановки граба, столкнулся с такой фигней:
Делаю снапшот, перехожу в нтот снапшот btrfs subvolume set-default 295 /, перезагружаюсь и граб выводит rescue, со словами - "не найден какой-то кусок граба по пути /@courent/boot и.т.д." То есть он ищет часть себя по полному пути, относительно нулевого тома. Любой снапшот, который будет называться НЕ /@courent больше не загрузится.
Выручайте.

[trs]

Если /boot сделать отдельным подтомом, то вносимые командой set-default изменения не должны на нём отражаться.