Btrfs в 2016

Точно, сонный перепутал определения, за что каюсь. И таки нет, она уже вроде бы в стэйбле, у себя на десктопе активно юзаю. Насчёт того, что весь диск можно отформатировать в ext - не знал, нигде не видел об этом упоминаний. А f2fs - тоже довольно интересная вещь, как появиться ssd - непременно попробую.

Чем угодно: cp или любимый гуй, или ещё какие-то другие способы.

Похоже, популярно ты не только объясняешь, но и мыслишь. Попробуй почитать man cp про reflink.

Странно... У меня почему-то всё работает. С радостью бы приложил скрин, да ядро компилится. Если только вечерком.

Если у тебя «дырявый» файл (т. е. созданный с помощью truncate -s РАЗМЕР ФАЙЛ, или с помощью записи нулей при включенном сжатии) — тогда всё может быть. Но это не является демонстрацией работы копирования ссылками.

Просто вместе с командой cp надо использовать --reflink=always, либо тыкать через гуй, тогда всё работает. И таки нет - файл со случайным набором данных из /dev/urandom.

Просто вместе с командой cp надо использовать --reflink=always

Так — да, работает. Потому что в cp из GNU coreutils в явном виде добавили поддержку btrfs. Но произвольное копирование данных (в т. ч. через произвольный гуй) не будет магически ускоряться btrfs.

И таки нет, она уже вроде бы в стэйбле

https://btrfs.wiki.kernel.org/index.php/Main_Page#Features

«In-band deduplication» в разделе «Features Currently in Development». Пока только руками утилиту запускать. Впрочем, тоже не худший вариант должен быть, как раз хотел на днях попробовать раздел под бакапы с btrfs. Включить сжатие, не архивировать и дедупликацию делать раз в какое-то время.

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

Я, напротив, нигде не видел упоминаний, что в Linux какую-то ФС на всё устройство сделать нельзя. Но ext точно делал, потому про другие не написал. :-) У btrfs тут преимущество в том, что она тома поддерживает. Наверное, отдельное упоминание из-за этого.

Так о магии речи и нет) Кстати, у меня вот так:

[hsnbrg@ALI ~]$ dd if=/dev/urandom of=test1 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.28262 s, 116 MB/s
[hsnbrg@ALI ~]$ df -BM /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda1         30720M 5322M    24008M  19% /
[hsnbrg@ALI ~]$ cp --reflink=always test1 test2
[hsnbrg@ALI ~]$ df -BM /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda1         30720M 5420M    23910M  19% /

И снэпшоты, снэпшоты замечательнейшая вещь @_@

Но из твоего исходного комментария складывается именно такое впечатление. Если бы ты написал «в btrfs можно сделать мгновенное и бесплатное копирование файла при использовании специальной команды» — вопросов бы не было.

Возможно ты прав. Что ж, все мы люди, все ошибаемся ;)

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

Тогда тебе нужно выкачать весь интернет. А вдруг война?

На плохом железе

Думаю обычный mdadm или btrfs у него была бы быстрей. zol на sata2 ssd:

SSD: SanDisk SDSSDRC032G
CPU: Intel(R) Atom(TM) CPU  230   @ 1.60GHz
2 Gb RAM

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

То скорость будет до 35 MB/s, с отключенным prefetch При этом на ext4/xfs/btrfs средняя скорость 88 MB/s.
Второй пример:

HDD: SATA3 2Tb TOSHIBA MQ01ABB200 over usb3
CPU: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz (burst to 3 Ghz)
8 Gb RAM

Сборка ядра наконец-то завершилась, и вот таковы результаты (всё же в btrfs с lzo сжатием приятно удивляет скорость):

[hsnbrg@ALI ~]$ df -BM /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda1         30720M 4545M    24598M  16% /

[hsnbrg@ALI ~]$ dd if=/dev/urandom of=test1 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.22476 s, 149 MB/s

[hsnbrg@ALI ~]$ sync && df -BM /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda1         30720M 5572M    23574M  20% /

[hsnbrg@ALI ~]$ cp --reflink=always test1 test2

[hsnbrg@ALI ~]$ sync && df -BM /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda1         30720M 5572M    23574M  20% /

Используй что-нибудь типо:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=3G --readwrite=randrw --rwmixread=75

> Просто вместе с командой cp надо использовать --reflink=always

Так — да, работает. Потому что в cp из GNU coreutils в явном виде добавили поддержку btrfs. Но произвольное копирование данных (в т. ч. через произвольный гуй) не будет магически ускоряться btrfs.

в GNOME — обычный файловый манагер как раз использует (поумолчанию) reflink=auto ..

примерно год назад — я сам удивился — когда случайно начал копировать (рядом) кучу гигобайтовых файлов, а этот процесс вдруг сделал это *мгновенно*

Тред не читал, но если dd используется для замены скорости то нужен fdatasync. Плюс, я не рекомендую юзать /dev/urandom, он может быть медленным для быстрых накопителей. У меня он только 240метров выдаёт например (на ноуте).

если dd используется

Нет, они дедупликацию тестируют.

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

Скорость чтения - она зависит прежде всего от твоего харда. Скорость записи - зависит от количества побочных операций (например, журналы) и твоего харда. Современные ФС ничем в этом плане особо не различаются (ну если ты NTFS не решишься заюзать - там тормоза, да). Только могут больше памяти жрать, etc. Тот же ext4 лично для меня вполне себе нормальный вариант. Если разделы часто не тасуешь - можно xfs (она уменьшаться не умеет). Всё остальное на ноутбуке - перебор.

на ssd это мастхэв, на hdd будет медленно даже с autodefrag

На HDD вполне норм, если это не /, /home, СУБД или виртуалки :)

Конечно нет. Лучше уж JFS или рейзер взять, чем это.

Что нет? На /srv на 2.5" HDD не вижу никаких проблем с быстродействием: торренты, зеркало Debian, медиаконтент для DLNA. А свои legacy-поделки без контроля целостности можешь вернуть в музей.

Сколько мегабит канал?

Это десктоп, неужели непонятно? :) 100 Мбит домашняя сеть.

В слаке

Не совсем понял о чём ты. А вот по поводу /dev/urandom - у меня обычный hdd, так что думаю разницы для меня нет. Хотя и в правду стало интересно, сейчас проверю.

У кого-нибудь был опыт использования в продакшене?

Плюс, я не рекомендую юзать /dev/urandom, он может быть медленным для быстрых накопителей. У меня он только 240метров выдаёт например (на ноуте).

[behem0th@ArchLinux ~]$ dd if=/dev/urandom of=/dev/null bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 3,8675 s, 278 MB/s

Ты про это ограничение в скорости говорил? А что тогда использовать?

что тогда использовать?

Я использовал https://wiki.archlinux.org/index.php/frandom .

mr_Heisenberg если один hdd то да :). А сколько щас современные винты жмут по скорости в линейных операциях? А то я за темой не слежу, я потихоньку на ssd стараюсь перебираться....

Понятия не имею) Моему HDD Western Digital Caviar Blue уже где-то 7-8 лет. Поскорее хочу прикупить новенький ноутбук и на SSD перейти. Но постоянно трачу деньги не туда. А вот по поводу скорости я писал чуть выше: на ntfs и ext4 этот HDD выдавал от силы 90Мб/с, а вот с btrfs и lzo сжатием уже до 150Мб/с в среднем. Замерял во время сборки ядра и после холодного старта