Ну может оно во время дефрагментации то данные раскладывает там по-всякому, подожди до конца, потом выводы сделаешь...

Удваиваю этого гражданина.

Кстати, ну понятное дело, что в свете SSD дефрагментация, себя изжила... А в свете HDD и всяких там планировщиков, NCQ, разве даёт реальный прирост производительности дефрагментация? - Ну скажем прирост 10-20 процентов..? ИМХО, не даёт, особливо на десктопе. А если говорить о серверах - так тем более не даст. Ибо никто никогда там её не делает, да и серверные приложения уже оптимизированны.

Это норма?

а что тебя смущает ?

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

нет конечно

музыка и видео уже cжатые так что там нечего сжимать.

разве даёт реальный прирост производительности дефрагментация?

ТС её запустил чтобы принудительно сжать все файлы, а не ради именно дефрагментации

ТС её запустил чтобы принудительно сжать все файлы, а не ради именно дефрагментации

Ах вот оно как, в brtfs. Ок. Но всё же мой вопрос остаётся в силе. :) Но в целом, я думаю там особо сжиматься нечему, если музыка, да фильмы...

Конечно, ожидать прироста в 10% глупо, но иногда прирост в 1-2% сильно ощутим, особенно на стареньких HDD (SATA, но не IDE, вторым уже ничто не поможет). Это особенно чувствуется на генте, где срез дерева портажа хранится на btrfs-подразделе с zlib-сжатием, а это тонна мелких файлов! При рассчёте зависимостей для кокого-нибудь жирного KDE или GNOME разница будет сильно заметна.

Именно. Как раз исходя из твоего совета в теме про флешку с btrfs.

Но метаданные здорово пожались.

Вот как потом отдать освободившееся место данным?

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

Ну если сжать какой-нибудь *mkv или *mp3, то архив будет больше чем сам файл.

Вот как потом отдать освободившееся место данным?

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

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

Еще одного винта на 2Тб нет. Есть еще один - на 500 Гб. Его можно как-то использовать для этой операции?

всё же мой вопрос остаётся в силе
разве даёт реальный прирост производительности дефрагментация?
- Ну скажем прирост 10-20 процентов..?

На совсем старых(~80gb) hdd, %10-20 даёт, а на новых особо и не заметно.

На hdd, когда raid'ы делал, то создавал массив не из всего объёма диска, а например только с первых 100GB... Из расчёта, чтобы база жёлтой программы влезла с 2x запасом.

Еще одного винта на 2Тб нет. Есть еще один - на 500 Гб. Его можно как-то использовать для этой операции?

Можно. Перемещай туда файлы, затем перемещай обратно.

А в свете HDD и всяких там планировщиков, NCQ, разве даёт реальный прирост производительности дефрагментация?

«Дерагментация» в Linux-системах (e4defrag, xfs_fsr; про btrfs не скажу, не щупал, но подозреваю, что то же самое) прироста производительности не даёт, так как изначально криво работает (не консолидирует свободное пространство, не сортирует каталоги). Если же проводить нормальную дефрагментацию (под Linux доступна только в виде перемещения на другой раздел), то прирост скорости на старых разделах офигенный. Всё просто летать начинает.

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

Ага. Как только дело доходит, например, до жирных многоуровневых кешей с тонной мелочи, то иногда приходится идти на жуткие извращения, типа, ставить reiserfs в файл, лежащий на ext4 :) Например, lvm на машине нет, переразбить удалённо невозможно, а ext4 одним томом страшно тормозит...

Когда есть lvm, то проще. И, да, приходится регулярно создавать новые разделы и переносить всё туда, делая «дефраг мувом». Иначе под высоким параллельным io всё встаёт колом. Вот, как пример реальной разбивки:

$ sudo df -lTh
Файловая система                       Тип      Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/balvg-gentoo64--root       ext4       9,8G         3,6G  5,7G           39% /
/dev/mapper/balvg-gentoo64--usr        ext4        30G         7,9G   21G           29% /usr
tmpfs                                  tmpfs      1,6G        1012K  1,6G            1% /run
/dev/sda1                              ext4        58G          31G   25G           56% /media/ssd
/dev/mapper/balvg-gentoo64--home       ext4        79G          64G   12G           86% /home
/dev/mapper/balvg-gentoo64--var        ext4        20G         7,5G   12G           41% /var
/dev/mapper/balvg-gentoo64--var--lib   ext4        40G          32G  6,0G           85% /var/lib
/dev/mapper/balvg-portage              ext4        30G          13G   15G           47% /var/portage
/dev/mapper/balvg-gentoo64--var--www   ext4        30G         7,0G   22G           25% /var/www
/dev/mapper/balvg-backup3              ext4       306G         273G   33G           90% /home/backup
/dev/mapper/balvg-family               ext4       168G         159G  696M          100% /home/family
/dev/mapper/balvg-astro                ext4       148G         140G  847M          100% /home/family/Astro
/dev/mapper/balvg-downloads2           xfs        400G         395G  5,5G           99% /home/family/Downloads
/dev/mapper/balvg-files                ext4       197G         158G   30G           85% /home/family/Files
/dev/mapper/balvg-music2               ext4       108G          97G  5,6G           95% /home/family/Music
/dev/mapper/balvg-family_our           ext4       689G         568G   89G           87% /home/family/Our
/dev/mapper/balvg-video3               xfs        2,0T         1,9T  124G           94% /home/family/Video
/dev/mapper/balvg-data                 ext4        69G          66G  4,0K          100% /data
/dev/mapper/balvg-small_files          ext4       128G          93G   29G           77% /mnt/data/small-files
/dev/mapper/balvg-owncloud             ext4        99G          36G   58G           38% /var/www/cloud.balancer.ru
/dev/mapper/balvg-lxc--airbase--caches reiserfs   100G          77G   24G           77% /home/airbase/mnt/caches
/dev/mapper/balvg-airbase--files       reiserfs   250G         135G  116G           54% /home/airbase/mnt/files
/dev/mapper/balvg-airbase--export      reiserfs   200G         124G   77G           62% /home/airbase/mnt/export
/dev/mapper/balvg-airbase--sites       reiserfs   100G          54G   47G           54% /home/airbase/mnt/sites
/dev/mapper/balvg-airbase--logs        ext4        40G          16G   23G           41% /home/airbase/mnt/logs
/dev/mapper/balvg-airbase2             reiserfs    50G          18G   33G           36% /var/lib/lxc/airbase/src
/dev/mapper/balvg-airbase--root--ext4  ext4        30G          19G  9,9G           65% /var/lib/lxc/airbase/dst

Можно. Перемещай туда файлы, затем перемещай обратно.

Тогда уже http://vleu.net/shake/

Но практически не поможет. Свободное пространство не консолидируется (скорее наоборот), сортировки по времени доступа не будет, группировки по каталогам не будет...

«Дерагментация» в Linux-системах (e4defrag, xfs_fsr; про btrfs не скажу, не щупал, но подозреваю, что то же самое) прироста производительности не даёт, так как изначально криво работает (не консолидирует свободное пространство, не сортирует каталоги)

Да ты че?! Файл разбитый на 100500 фрагментов по всему диску и тот же файл один куском работают одинаково? Seek по диску роли не играет уже. Ну-ну, пиши еще!

когда файлы будут назад заливаться, btrfs их распознает - что они несжимаемые

по окончанию, можно выполнить: btrfs balance start / -v -musage=75 -dusage=75

Свободное пространство не консолидируется (скорее наоборот), сортировки по времени доступа не будет, группировки по каталогам не будет...

ты не читал тему, мы тут про сжатие в btrfs говорим, оно делается командой «btrfs defrag», дефрагментацию никто тут делать и не собирался

мы тут про сжатие в btrfs говорим

Самое смешное, что всё сказанное мной остаётся в силе и в таком варианте :D

про сжатие в btrfs говорим, оно делается командой «btrfs defrag»

Оригинальное название команды, да...

Оригинальное название команды, да...

это просто набор символов... halt же тебя не напрягает

halt же тебя не напрягает

В ассемблере — нет. Остановка есть остановка. В других местах не сталкивался.

это просто набор символов

А почему тогда не btrfs asdfg? :)

Остановка есть остановка

но она же называется halt, а не ostanovka... )

но она же называется halt, а не ostanovka... )

?

к тому что набор символов не должен парить

что в свете SSD дефрагментация, себя изжила

Больше экстентов — больше метаданных, дольше доступ.

про сжатие в btrfs говорим, оно делается командой «btrfs defrag»

Оригинальное название команды, да...

Это просто побочный эффект, на сколько я тут понял тему. Команды «сжать лежащее на диске» нет, надо перезаписать файлы после включения соответствующей опции у ФС. А дефрагментация это и делает. С тем же успехом можно было мувнуть с места на место, но defrag проще, так как сам всё сделает.

это просто набор символов...

Это не набор символов, а сокращение от слова с вполне конкретным значением. Если ты английский не знаешь, это не значит, что другие не знают. ;-)

пишу цифры по памяти

вряд ли метаданные занимали тогда столько места

Правда, дефрагментация еще идет

facepalm

почитай, как выполняется дефрагментация на любой фс

Параметры монтирования ФС: defaults,clear_cache,autodefrag,compress=zlib

не фонтан

лучше бы так: noatime(relatime по желанию),space-cache,compress=lzo,autodefrag

а ещё лучше - включить nodatacow (тогда, правда, отключится сжатие, но на музыке и видео оно и ни к чему)

Больше экстентов — больше метаданных

а не наоборот?

ах да, и лимит на интеграцию файла в дерево метаданных на HDD лучше повысить, наверное, чтобы головки меньше туда-сюда бегали

В других местах не сталкивался.

man halt же. :-)

интересно, а если выставить max_inline, скажем, в 1 Тб, btrfs реально все файлы будет в дерево метаданных впихивать? -))

а давайте ещё вопрос другой обсудим: об BTRFS и дефрагментации?

[чтобы новую тему не плодить]

как мы понимаем дефрагментация нужна (ну не то чтобы прям «нужна».. но, скажем так — положительно влияет) — именно для *механических* HDD.

так как это существенно ускоряет отклик (головка меньше елозит в поисках разных секторов разных фрагменов).

а для SSD-накопителей дефрагментацию не делают, так как на SSD поиск секторов и без этого происходит мгновенно (головки нет. ни кто не елозит)

...и вот у меня возник следующий вопрос:

а может ли так получиться что дефрагментация положительно скажется *даже* и на SSD-устройствах?

например, потому что SSD-устройства считывают данные большими порциями, и если все данные файла окажутся внутри одной такой большой порции, то SSD-устройство не станет делать лишних чтений?

или, например, потому что SSD-устройство имеет (как и механический HDD) некоторый кэш (в виде собственной оперативной памяти), и постоянные лишние чтения разных областей — забивают этот кэш ненужным говном?

Поздно, у меня вчера ФС посыпалась после сбоя питания. Сделал btrfs check со всеми параметрами, что ещё можно предпринять?

не знаю, ни разу не сталкивался с такой ситуацией

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

ФС посыпалась после сбоя питания

Я как раз из-за устойчивости к сбоям питания btrfs выбрал.

И что, много потерялось?

Сегодня буду плотнее разбираться с этим.

Снапшоты могут помочь? Стоит ли их регулярно делать?

Снапшоты не уберегут данные, если метаданные накроются медным тазом. Но если их хранить на отдельном томе, то.

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

что ещё можно предпринять?

Развернуть бэкап на нормальую ФС и не трогать больше каку.

Что скажешь о ZOL? С ней я могу спать спокойно?

... и не трогать больше каку.

но ведь про ZFS-какашки как раз в этой теме ни кто и не упомянал :-)

вчера ФС посыпалась после сбоя питания

какая версия ядра?

какая версия ядра?

3.19.3-gentoo

это печально :) .. (для нас всех)

вчера ФС посыпалась после сбоя питания

а можно ли предположить что сам процесс конвертирования не прощёл до конца гладко?

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

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

Это норма?

Ну несколько лет назад для бтрфс нормой было внезапное увеличение свободного пространства до 100%

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

Как это напоминает старые добрые времена и двигалки разделов с hpfs...

Поздно, у меня вчера ФС посыпалась после сбоя питания.

А раздел важный был для системы, или как ? Система загрузилась ? Думаю вот /vat/log/чего-нибудь, для статистики, в btrfs перевести... Но вот что будет с автопроверкой ?.. У кого-нибудь в rc.sysinit (у кого есть, конечно :-) ) что-то про btrfs есть ?

автопроверки не нужны