BTRFS. Готова ли к использованию в 16.04?

[abdula_8]

Sly_tom_cat, круто, спасибо, буду пробовать. Вот почитал про ключи. Дефрагментировать хочу со сжатием. Есть такой ключ: -t size        минимальный размер файла для дефрагментации.  Тут указано, что https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_speed_penalties_when_doing_random_access_to_a_compressed_file.3F что для файлов менее 128 кб сжатие даёт понижение производительности, ибо сжатый блок =128 кб, а если в нем нужен один файл на 1кб, то считывают и распаковывают весь блок ради этого. И собственно вопрос. Если я укажу в этом ключе минимальный размер для дефрагментации в 129 кб, это будет правило для всех последующих файлов даже после перезагрузок? Или я не могу указать навсегда минимальный размер файла, который нужно сжимать?
Про ядро. Я на Ubuntu 16.04, а ядро стоит 4.5 xanmod. На родном ноут не засыпает, ну и надеюсь у ксанмода оно и правда быстрее) Ноут при этом тормоз что на одном, что на втором.

(Нажмите, чтобы показать/скрыть)

Про молниеносность загрузки: systemd-analyze blame
      3min 477ms powerd.service
    2min 17.294s apt-daily.service
          5.948s dev-sda4.device
          5.630s preload.service
          5.599s ModemManager.service
          5.208s accounts-daemon.service
          4.935s grub-common.service
          4.401s irqbalance.service
          4.262s apport.service
          4.075s networking.service
          4.062s console-kit-log-system-start.service
          4.046s systemd-logind.service
          4.001s speech-dispatcher.service
          3.958s pppd-dns.service
          3.940s gpu-manager.service
          3.937s thermald.service
          3.923s avahi-daemon.service
          3.922s bluetooth.service
          3.682s alsa-restore.service
          3.675s systemd-user-sessions.service
          3.664s rsyslog.service
          2.095s console-kit-daemon.service
          2.059s apparmor.service
lines 1-23...skipping...

[thunderamur]

thunderamur, ну тогда почему бы раид на btrfs и не попробовать?

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

[Sly_tom_cat]

thunderamur, разве mdraid по дефолту позволяет на деградировавшем RAID массиве загрузиться? Вроде как том тоже надо было хвост накручивать... или я путаю 
Пользователь добавил сообщение 27 Апреля 2016, 16:46:31:abdula_8, нужно различать сжатие при дефрагментации и сжатие настроенное ключами монтирования которое делается на автомате все время пока с ними смонтирована FS.

В btrfs правда про сжатие есть еще один путь - делать его через атрибуты подтомов и каталогов, но это хорошо только при ручном создании подтомов перед установкой OS. В атрибутах управления тем какого размера жать а какого нет - нет. В ключах монирования - надо бы посмотреть, но на память вроже как не было тоже. Но гдето мне попадались слова что сжатие не делается драйвером если он считает, что от него не будет толку...
Пользователь добавил сообщение 27 Апреля 2016, 16:46:23:В ключах монтирования есть две опции:

compress, и compress-force

compress-force=<method> - Enable compression even for files that don't compress well, like videos and dd images of disks.

т.е. опция compress - это как бы "паковать только то, что хорошо пакуется" 

[thunderamur]

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

(Нажмите, чтобы показать/скрыть)

Вот есть же кнопочка для сбора постов в кучу.

[EvangelionDeath]

Ещё вопрос. Когда ставлю флаг lazytime, то показывает, что примонтировам и с ним, и с realtime. Почему и как исправить?
Спасибо.

Потому что lazytime - это "улучшенная" версия realtime. То есть realtime теперь не сразу сбрасывает время при изменении, а только когда придет время сбросить кеш с ОЗУ для dirty. Как то так. Надеюсь мое сообщение Вам прояснило ситуацию.

[abdula_8]

EvangelionDeath, да, прояснило, спасибо)
Sly_tom_cat, сделал дефрагментацию и балансировку. Безрезультатно.
Ещё интересная штука:

(Нажмите, чтобы показать/скрыть)

/dev/sda:
 Timing cached reads:     2 MB in  2.58 seconds = 792.52 kB/sec
 Timing buffered disk reads:  48 MB in  3.02 seconds =  15.92 MB/sec
----
deadline
noop [deadline] cfq
3

/dev/sda:
 Timing cached reads:   2726 MB in  2.00 seconds = 1363.07 MB/sec
 Timing buffered disk reads:  24 MB in  3.21 seconds =   7.48 MB/sec
----
cfq
noop deadline [cfq]
3

/dev/sda:
 Timing cached reads:   5414 MB in  2.00 seconds = 2708.70 MB/sec
 Timing buffered disk reads:  36 MB in  3.03 seconds =  11.87 MB/sec

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

[EvangelionDeath]

EvangelionDeath, да, прояснило, спасибо)
Sly_tom_cat, сделал дефрагментацию и балансировку. Безрезультатно.
Ещё интересная штука:

(Нажмите, чтобы показать/скрыть)

/dev/sda:
 Timing cached reads:     2 MB in  2.58 seconds = 792.52 kB/sec
 Timing buffered disk reads:  48 MB in  3.02 seconds =  15.92 MB/sec
----
deadline
noop [deadline] cfq
3

/dev/sda:
 Timing cached reads:   2726 MB in  2.00 seconds = 1363.07 MB/sec
 Timing buffered disk reads:  24 MB in  3.21 seconds =   7.48 MB/sec
----
cfq
noop deadline [cfq]
3

/dev/sda:
 Timing cached reads:   5414 MB in  2.00 seconds = 2708.70 MB/sec
 Timing buffered disk reads:  36 MB in  3.03 seconds =  11.87 MB/sec

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

И так пи тесте noop у вас вообще странный результат Timing cached reads:     2 MB in  2.58 seconds = 792.52 kB/sec - это шутка такая?
Ну и делать его надо, когда нет других активных процессов. Кроме того Timing buffered disk reads не зависит от файловой системы.

Что у Вас за ХДД такой?

[abdula_8]

EvangelionDeath, да, я шутку тоже оценил. Тесту ничего или почти ничего не мешает. Я его мнооого раз делал, там самые разные цифры, но чаще низкие, а вот комп тормозит и медленно включается всегда.  Но показатели не всегда такие, иногда даже 100 мб выдаёт, хотя на скорость работы это не влияет. Диск ноутбучный TOSHIBA MQ01ABD100, 1тб, 7200 скорость. Переразбил диск, жду, когда скопируются данные на раздел ext4. Да, поставил туже самую Ubuntu на другой корень, а home остался на бтрфс. Версия, где корень на ext4 грузится в несколько раз быстрее. Ладно бы я что-то активно ломал, но тут ведь всё дефолтное, и такая жесть. Видать рано начали про её стабильность петь.

Молю о помощи! Я не могу скопировать данные на другой раздел с человеческой фс. Копирует бОльшую часть, а потом скорость падает не нескольких кб/с. Мне не охота ждать неделями. На те огрызки, что скопировались система грузиться не хочет. С лайвСД тоже самое. С раздела на ext4 тоже самое, только загружается он быстрее, а все операции с хомяком адски медленные. Интересно как оживить бтрфс, а также спсоб копирования данных с диска на диск быстрее, чем обычное копировать-вставить. Спасибо.

[Kekek]

Поставил две разные системы в одну файловую систему BTRFS в разные подтома. Через GRUB можно выбирать, какую систему грузить.

[Sly_tom_cat]

abdula_8, у вас похоже на какой-то чуть ли не аппаратный глюк. SMART диска смотрели? Все там ок?

[EvangelionDeath]

abdula_8, Давайте данные S.M.A.R.T. и покажите таблицу разделов. Да, и как это он у Вас 7200, если в ноутбуки в 99% случаев ставят 5400 RPM, да и в официальных характеристиках значится 5400. Так же желательно предоставить конфигурацию лэптопа: процессор, озу, интерфейс подключения самого хдд. У меня плохое предчувствие, что Ваш системный раздел находится где-то в хвосте ХДД

[thunderamur]

Red Hat Enterprise Linux 6.8 Deprecates Btrfs

Как вам такое?

[Sly_tom_cat]

thunderamur, возня в песочнице, ИМХО.

На мой взгляд красношапошники вообще довольно странными вещами занимаются в последнее время....

И вот:

That document only refers to RHEL6 where btrfs was merely a technology preview. No matter what the wording may indicate, if it's not written in letter in the upcoming 7.3 release notes, it simply does not apply to RHEL7.

[thunderamur]

Sly_tom_cat, ага, фуфел какой-то

Update: I've now been able to confirm with Red Hat that this change affects RHEL6 only and that Btrfs will be supported in RHEL7, still bad wording in the documentation.

Короче все норм.

[AnrDaemon]

Сделал себе такой вот upstart helper для монтирования.

Код: [Выделить]

description "Mounting subvolume @xxx"
author      "AR <anrdaemon@yandex.ru>"

# Primary mounting route.
# Mount after /dev is ready or when "mounting TYPE=btrfs" emits.
start on virtual-filesystems or mounting TYPE=btrfs

# Alternatively, if you need another directory mounted before mounting
# this partition (i.e. you want to mount @backup subvol into /somedir/backup,
# where /somedir itself is a mount point):
#start on (virtual-filesystems or mounting TYPE=btrfs) and mounted MOUNTPOINT=/somedir

task

env UUID="84fe8962-f8a9-47ab-b758-3aa7b0f4bef3"
env VOLUME="@xxx"
env TARGET="/xxx"
env OPTIONS="relatime"

console log

pre-start script
  logger -ist $UPSTART_JOB -- Starting $UPSTART_JOB...
  test -d "$TARGET" || mkdir --parent "$TARGET"
end script

exec /bin/mount ${VERBOSE:+-v} "/dev/disk/by-uuid/$UUID" "$TARGET" -t btrfs -o "subvol=$VOLUME${OPTIONS:+,}$OPTIONS"
Почему-то pre-start не отрабатывает, хотя монтирует исправно.
Пользователь добавил сообщение 22 Мая 2016, 21:57:18:А, не, всё отрабатывает. Хотя конечно странно. В логах пусто.
Надо будет ещё одну весчь попробовать.