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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
