LINUX.ORG.RU

BTRFS: rm: cannot remove 'xxx': No space left on device

 ,


0

5

В ознакомительном порядке начал осваивать перспективную (как пишут в сети) файловую систему - BTRFS. Создал виртуальный диск для на виртуальной машине (DEBIAN), игрался с ним, встал вопрос оптимизации реального дискового пространства на хосте. Для этого попробовал занулить свободное место на виртуальном диске, чтоб потом можно было его схлопнуть. Зануление проводил с помощью sfill:

#> sfill -l -l -z -f -v
Принцип работы этой утилиты заключается в создании гигантского пустого файла (с нулями), заполняющего всё оставшееся пространство, и последующем его удалении. Вот на удалении и возникла ошибка в заголовке. Гугление не помогло. Находил много подобных проблем (не всегда таких же), но решений предложено гораздо меньше и ни одно из них мне не помогло. Смоделировал такую же ситуацию с пустым (изначально) виртуальным диском, но не с первого раза. Вот что имеем:
#> btrfs fi df /mnt
	System, single: total=4.00MiB, used=4.00KiB
	Data+Metadata, single: total=8.00GiB, used=7.98GiB
	GlobalReserve, single: total=164.00MiB, used=145.38MiB
#> mount | grep /dev/sdb
	/dev/sdb on /mnt type btrfs (rw,noatime,nodatasum,nodatacow,nossd,nospace_cache,clear_cache,enospc_debug)
#> ls -Al /mnt
	total 8355588
	-rw------- 1 root root 8556122112 Nov 15 08:14 oooooooo.ooo
#> rm -r -f /mnt/oooooooo.ooo
	rm: cannot remove '/mnt/oooooooo.ooo': No space left on device
#> echo > /mnt/oooooooo.ooo
	bash: /mnt/oooooooo.ooo: No space left on device
#> dmesg
	...
	[19226.492770] BTRFS info (device sdb): setting nodatacow, compression disabled
	[19226.492777] BTRFS info (device sdb): force clearing of disk cache
	[19226.492782] BTRFS info (device sdb): disabling disk space caching
	[19226.492786] BTRFS: has skinny extents
	[19226.501538] BTRFS: detected SSD devices, enabling SSD mode
	[19658.904879] BTRFS info (device sdb): disk space caching is enabled
	[19658.904883] BTRFS: has skinny extents
	[19658.912321] BTRFS: detected SSD devices, enabling SSD mode
	[19719.743095] BTRFS info (device sdb): disk space caching is enabled
	[19721.795072] BTRFS info (device sdb): disk space caching is enabled
	[19722.763731] BTRFS info (device sdb): disk space caching is enabled
	[19917.465373] BTRFS info (device sdb): not using ssd allocation scheme
	[19917.465388] BTRFS info (device sdb): disabling disk space caching
	[19917.465393] BTRFS info (device sdb): setting nodatacow, compression disabled
	[19917.465402] BTRFS info (device sdb): force clearing of disk cache
	[19917.465405] BTRFS: has skinny extents
	[19934.376503] BTRFS info (device sdb): disabling disk space caching
	[19939.483187] BTRFS info (device sdb): disabling disk space caching
	[19945.093364] BTRFS info (device sdb): disabling disk space caching
	[19947.757522] BTRFS info (device sdb): disabling disk space caching
Видно, что диск забит на 99% единственным файлом, удалить который невозможно. Проверка файловой системы ошибок не выдает. Все файлы на диске доступны для чтения. Пробовал манипуляции с монтированием на чтение и последующим двойным перемонтированием на запись, пробовал опции монтирования nodatacow, nospace_cache, clear_cache, enospc_debug. Соответственно ничего не помогло. У меня идеи кончились, решил зарегистрироваться на форуме, написать сюда. Понятно, что в случае с виртуальным диском это не проблема. Но что делать, если диск реальный и на нем есть полезные данные. Можно их скопировать на другой носитель, опять же при его наличии, а дефектный отформатировать. А есть ли альтернативный путь?

Data+Metadata

Что это, mixed? Так делать не рекомендуется.

А есть ли альтернативный путь?

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

anonymous
()
Ответ на: комментарий от alexander_baranov

ну, по той же ссылке пишут и как спастись, вобщем-то...

The main issue is that the allocation units (chunk size) are very large compared to the size of the filesystem, and the allocation can very quickly become full. A btrfs fi balance may get you working again, but it's probably only a short term fix, as the metadata to data ratio probably won't match the block allocations.
If you can afford to delete files, you can clobber a file via
echo > /path/to/file
which will recover that space without requiring a new metadata allocation

aol ★★★★★
()
Ответ на: комментарий от alexander_baranov

Тащемта малый объём это один, максимум пять гигабайт. По ссылке не ходил, ссылаюсь на ман. Так или иначе, Btrfs со своим гигабайтным чанком никак и никогда не будет нормально работать на маленьких объёмах. Вон, свидетели ZFS вообще утверждают, что если ты не можешь всегда держать свободными 20-25% стораджа, то ты лох и ССЗБ :) По своему опыту могу сказать, что на Btrfs желательно иметь 10-20 Гб свободных во избежание удивительных ENOSPC.

anonymous
()
Ответ на: комментарий от aol

ну, по той же ссылке пишут и как спастись, вобщем-то...

читаем внимательно первый пост:

#> echo > /mnt/oooooooo.ooo
bash: /mnt/oooooooo.ooo: No space left on device

alexander_baranov
() автор топика
Ответ на: комментарий от alexander_baranov

читаем внимательно первый пост

мнелеееень... :-D

а еще в моей цитате кроме echo > есть еще вызов какого-то баланса. у тебя в ОП этих пассов нет.
сам я не бтрфс усер, могу только маны поцитировать. но ты попробуй :)

aol ★★★★★
()
Ответ на: комментарий от anonymous

... если ты не можешь всегда держать свободными 20-25% стораджа, то ты лох и ССЗБ :)

Согласен, в случае с SSD так тем более. Но вопрос всё еще открыт.

alexander_baranov
() автор топика
Ответ на: комментарий от aol

мнелеееень... :-D

Понимаю)))

есть еще вызов какого-то баланса

тоже опробовано, и по той же причине не дает, говорит мол места у тебя нет

alexander_baranov
() автор топика
Ответ на: комментарий от futurama

Чем ему так поможет баланс на смешанном томе?

anonymous
()
Ответ на: комментарий от alexander_baranov

Но вопрос всё еще открыт.

Ответ в первом комментарии. Btrfs пишут люди, и с ними даже можно разговаривать.

anonymous
()

Мне пока лень проводить эксперимент, но мне кажется, что в debian ядро старовато для btrfs. Поддержка конечно есть, но не для ежедневного использования.

surefire ★★★
()
Ответ на: комментарий от anonymous

Ответ в первом комментарии. Btrfs пишут люди, и с ними даже можно разговаривать.

Спасибо, уже сделал это.

alexander_baranov
() автор топика
Ответ на: комментарий от surefire

в debian ядро старовато для btrfs

4.8 вполне нормально.

anonymous
()
Ответ на: комментарий от anonymous

Ответ в первом комментарии. Btrfs пишут люди, и с ними даже можно разговаривать.

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

anonymous
()
Ответ на: комментарий от surefire

в debian ядро старовато для btrfs

Возможно, ядро ставил из стандартного репозитория, версия 3.16.0-4-amd64. Вроде как поддержка BTRFS была включена еще с версии 2.х... Наивно полагаю, что к настоящему моменту все детские болезни должны быть вылечены...

alexander_baranov
() автор топика

mixed mode виноват:

 -M|--mixed

    Normally the data and metadata block groups are isolated. The mixed mode will remove the isolation and store both types in the same block group type. This helps to utilize the free space regardless of the purpose and is suitable for small devices. The separate allocation of block groups leads to a situation where the space is reserved for the other block group type, is not available for allocation and can lead to ENOSPC state. 
Как починить не знаю, странно что clobber не помогает. Попробуй truncate -s 0 /mnt/oooooooo.ooo

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

disarmer ★★★
()
Ответ на: комментарий от alexander_baranov

Настоящий момент: ядро 4.8; ты думал что в 3.16 все само собой лечится со временем? нет, это все тоже ядро 3.16 со своим набором проблем в поддержке btrfs

anonymous
()

Предлагаю наркоманский вариант: сделать блочное устройство в оперативке, на него расширить фс, снести файл, шринкнуть обратно, убрать блочное устройство.

Deleted
()
Ответ на: комментарий от anonymous

Настоящий момент: ядро 4.8; ты думал что в 3.16 все само собой лечится со временем? нет, это все тоже ядро 3.16 со своим набором проблем в поддержке btrfs

Настоящий момент для DEBIAN - 3.16. Само собой, к сожалению, ничего не лечится, но я, очевидно, наивно полагал что с момента официального включения поддержки BTRFS в ядро (повторюсь, насколько я помню, это 2.х) к версии 3.16 (пусть не самой передовой), такой баг уже обнаружили и исправили.

alexander_baranov
() автор топика
Ответ на: комментарий от disarmer
#> truncate -s 0 /mnt/oooooooo.ooo
	truncate: не удалось усечь «/mnt/oooooooo.ooo» на 0 байт: На устройстве не осталось свободного места

:( Всё равно спасибо за участие!

alexander_baranov
() автор топика
Ответ на: комментарий от Deleted

Предлагаю наркоманский вариант: сделать блочное устройство в оперативке, на него расширить фс, снести файл, шринкнуть обратно, убрать блочное устройство.

Большое спасибо, да, это действительно помогло. Но очень интересно: сделал одно петлевое устройство на 64М, добавил к ФС, его оказалось недостаточно. Запрос свободного места показал 100% занятости! Как будто бы файл распух ровно на количество добавленного пространства. Удалить файл всё еще было невозможно. Я пошел дальше и пришил еще 64М, и вот тут (о чудо!) появилось немного свободного места, что позволило удалить злополучный файл. Такое странное поведение я связываю с опцией no-holes, которую я указал при создании ФС. Она призвана каким-то образом оптимизировать «дырявые» файлы (насколько я понял). А в моём случае файл представлял одну большую ДЫРУ.

Мои благодарности всем откликнувшимся!

alexander_baranov
() автор топика
Ответ на: комментарий от alexander_baranov

P.s. Дело в том, что btrfs дорабатывают даже в релизах минорных версий, не говоря уж о мажорных.

mr_Heisenberg
()

Принцип работы этой утилиты заключается в создании гигантского пустого файла (с нулями), заполняющего всё оставшееся пространство, и последующем его удалении.

то же самое что dd if=/dev/zero of=/mnt/bla/111 bs=1M & rm /mnt/bla/111 ?

theurs ★★
()
Ответ на: комментарий от alexander_baranov

Возможно, ядро ставил из стандартного репозитория, версия 3.16.0-4-amd64. Вроде как поддержка BTRFS была включена еще с версии 2.х... Наивно полагаю, что к настоящему моменту все детские болезни должны быть вылечены...

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

val-amart ★★★★★
()
Ответ на: комментарий от alexander_baranov

такой баг уже обнаружили и исправили.

это даже не совсем баг. это особенность конструкции фс. ты же не считаешь багом если например на ext3 у тебя закончатся inodes?

val-amart ★★★★★
()
Ответ на: комментарий от alexander_baranov

Такое странное поведение я связываю с опцией no-holes, которую я указал при создании ФС. Она призвана каким-то образом оптимизировать «дырявые» файлы (насколько я понял).

я рекомендую внимательно читать и понимать до конца маны. no-holes не аллоцирует экстенты метаданных на т.н. «holes», экономя таким образом метаданные (экстенты данных на дыры не аллоцируются в любом случае, разумеется). «дыры» это если ты не вкурсе когда ты например записываешь байт, потом пишешь следующий с offset, например сделав fseek(3). к твоей ситуации вообще отношения не имеет, если ты правильно описал modus operandi своей «писалки».

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

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

INFOMAN ★★★★★
()
Ответ на: комментарий от Deleted

вся красота Линукса вот в этом вот

anonymous
()
Ответ на: комментарий от alexander_baranov

Такое странное поведение я связываю с опцией no-holes, которую я указал при создании ФС

ты же отключил разреженные файлы на уровне фс

anonymous
()
Ответ на: комментарий от val-amart

это даже не совсем баг. это особенность конструкции фс. ты же не считаешь багом если например на ext3 у тебя закончатся inodes?

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

NightOperator ★★★
()

Господа, перестаньте насиловать труп..
reiser-4 уже с нами! с сентября 2016-го, внезапно и неожиданно!
для / есть ext2/ext3/reiser-3.6. монтирование и разбивка дисков таки не зря придумана, не так ли?

anonymous
()
Ответ на: комментарий от anonymous

Вон, свидетели ZFS вообще утверждают, что если ты не можешь всегда держать свободными 20-25% стораджа, то ты лох и ССЗБ :)

Ещё один повод не преходить на неё :) А то жалко на винте на 4Тб терять 1Тб места :D

KRoN73 ★★★★★
()
Ответ на: комментарий от NightOperator

Это именно баг

Если баг описан и официально объясняется, то это не баг, а фича. Конечно, не делающая BTRFS менее идиотской от этого :D

...

Впрочем, на ext4 я несколько раз натыкался на повреждение уже имеющихся файлов при переполнении раздела. Это хуже :) Но, правда, в последние годы на такое не натыкался. Не знаю, то ли потому что ext4 допилили, то ли совсем редкое стечение обстоятельств было, то ли потому что все легко переполняющиеся хранилища (торренты и т.п.) у меня нынче под xfs :)

KRoN73 ★★★★★
()

cannot remove 'xxx': No space left on device

Чтоб удалить что-то ненужное, надо создать что-то ненужное. А на это места уже не хватает.

devl547 ★★★★★
()

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

anonymous
()

Ты пробовал :>/mnt/oooooooo.ooo вместо rm?

anonymous
()
Ответ на: комментарий от anonymous

А что произошло в сентябре?

Шишкин сделал пару фич в Reiser4. Некоторые до сих пор в эйфории.

greenman ★★★★★
()
Ответ на: комментарий от NightOperator

К слову в ZFS есть похожая проблема, но там банальный

>файл_которого_не_жалко

решает проблему. При том что rm жалуется на отсутствие космоса^W^W^W no space left on device :-)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Deleted

Тоже верно, если рассматривать операцию mv грубо как cp и rm

Pinkbyte ★★★★★
()
Ответ на: комментарий от EvgGad_303

Keep pool capacity below 90% for best performance

На сколько below и о каком размере pool'a идет речь?

Ты как всегда слишком восторженно говоришь всякую хрень, не имея никакого реального опыта. Очередное: «ко-ко-ко, zfs лучше всех, а я Д'Артаньян»

anonymous
()
Ответ на: комментарий от EvgGad_303

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

futurama ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.