Re: Crash in __btrfs_reserve_extent

Tore Anderson
2009-08-06T14:15:21Z

Hello Josef,

* Josef Bacik

> This is one of the gotchas of btrfs, there is not proper ENOSPC
> handling, just a few things in place that are a bit conservative to
> make sure you don't panic the box. Btrfs has seperate zones used for
> data and metadata, and these chunks are allocated in 1gb chunks, so
> you have 212gb of space thats allowed for data use, and 16gb thats
> allowed for metadata use. By default every 12 (or it may be 8, i
> forget) chunks we allocate for data, we allocate 1 for metadata,
> which ends up with like 8% of the disk being used for metadata.

Hmm, okay. I was aware of the fact that it didn't handle the disk
filling up too well, but I didn't know that would cause an issue so long
before the disk has gone full? I mean, according to df my there's 16 GB
of files on my disk (something I verified with du), while according to
you there should be 212 GB available for that in total.

Has metadata and data _both_ been stored in the 16 GB zone reserved for
metadata, for some reason? It would make sense that I ran into ENOSPC
in that case, since the metadata-reserved zone now is indeed completely
full. If I understand you correctly, though, the data is stored in the
212 GB large zone, not the 16 GB large metadata zone - but if that's the
case I don't understand how I could have hit ENOSPC?

> Now in your case you can run btrfsctl -b and it will re-balance the
> space on the drive, and it may give you more space back. It could
> also possible panic the box, so make sure you are all backed up :).

Thanks for the tipe, but the "-b" option doesn't seem to be present in
btrfsctl (built from a day-fresh git checkout)...?

Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27