Опции создания и опции монтирования btrfs

Мда, эта ваша btrfs...
Создаю raid1 из двух хардов по 1Т - mkfs.btrfs -m raid1 -d raid1 /dev/sd[c,d]1, монтируем это дело без компрессии (она всё равно не работает)
Логично предположить, что должен получится раздел размером 1Тб, но нет, df кажет 1,9Тб свободного места.
Продолжаем, создаю на разделе образы виртуалок:

qemu-img create -f qcow2 -o size=100T,preallocation=metadata data.img

Нетрудно заметить, что размер файла с преалокейшном 100Тб, после создания файла df уверенно рапортует, что на разделе занято 2Гб. Создав десяток файлов по 100Тб каждый, места стало занято аж 7Гб.

Я даже боюсь представить, что будет с этим разделом и с этими файлами, если я запущу на них ВМ.

Вот такая вот офигительная ФС.

compress=lzo при монтировании. Жмет вполне себе

compress=lzo при монтировании. Жмет вполне себе

У меня не жмёт. btrfs v.0.19.

А то что можно создавать файлы с размером многократно превышающем размер раздела тебя не смущает?

btrfs filesystem df /

И что? Показывает цифры не имеющие отношения к реальному положению вещей. Повторяю, на диске 1,9Тб сейчас находятся файлы общим объёмом 1000Тб.

Я даже боюсь представить, что будет с этим разделом и с этими файлами, если я запущу на них ВМ.

Я даже боюсь представить, что будет с этим разделом и с этими файлами, если я запущу на них ВМ.

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

Это не баг а фича. Хуже если бы файл размером больше раздела нельзя было записать, даже если он в сжатом виде помещается.

А как оно там на других ФС со сжатием?

Повторяю, на диске 1,9Тб сейчас находятся файлы общим объёмом 1000Тб.

Ну и что тебя это так насторажило. Жмет же?

УМВР, рейдов нет,
создания огромного файла с нулями не забирает место, создание файла из рандома забирает.
все прикрасно мониторится через
btrfs filesystem df /

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

df на btrfs неадекватно работает, это известный факт.

Жмет же?

Монтирую без опции compress.

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

Это не правильно, файл с преалокейшном должен сразу отжирать отведённое под него место, иначе крах ФС неминуем при записи в эти файлы.

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

Завтра попробую проверить, но меня априори такое поведение ФС не устраивает.

df на btrfs неадекватно работает, это известный факт.

Как показывают мои нехитрые тесты не только df.

все прикрасно мониторится через btrfs filesystem df /

root@ubuntu-srv:/# btrfs filesystem df /mnt/btrfs
Data, RAID0: total=38.00GB, used=20.95GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=38.00GB, used=104.65MB
Metadata: total=8.00MB, used=0.00

Это нормальный мониторинг?

Кстати рейд кривой, я явно указывал при создании -m raid1 -d raid1, а что получилось? Порно какое то.

Например, что ещё?

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

King_Diamond

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

вообще-то так можно и на NTFS и на EXT3,4. Просто файлы не сжатые, а разряжённые. http://ru.wikipedia.org/wiki/Разрежённый_файл

King_Diamond

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

и что? man cp

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made sparse as well. That
is the behavior selected by --sparse=auto. Specify --sparse=always to create a sparse DEST file whenever the SOURCE file con-
tains a long enough sequence of zero bytes. Use --sparse=never to inhibit creation of sparse files.

вообще-то так можно и на NTFS и на EXT3,4. Просто файлы не сжатые, а разряжённые.

Да, точно, я ламер. Осталось с raid1 разобраться.

С raid1 вопрос тоже снят, получилось. Всем спасибо.