Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-30 Thread Marc Haber
On Mon, Nov 30, 2015 at 05:44:23AM +, Duncan wrote: > Yes, you can get dup metadata back, but because data and metadata > are now combined in the same blockgroups (aka chunks), they must > both be the same replication type. Thanks for this explanation, it's perfectly clear to me now.

Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-29 Thread Marc Haber
Hi Hugo, On Sun, Nov 29, 2015 at 02:18:06PM +, Hugo Mills wrote: > On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote: > > However, the FAQ > > https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21 > >

Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-29 Thread Hugo Mills
On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote: > Hi, > > I have a banana pi with a btrfs filesystem of 5 GB in size, which > frequently runs out of space (lots of snapshots). This is currently > again the case: > > [27/524]mh@banana:~$ sudo btrfs balance start / > ERROR: error

"disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-29 Thread Marc Haber
Hi, I have a banana pi with a btrfs filesystem of 5 GB in size, which frequently runs out of space (lots of snapshots). This is currently again the case: [27/524]mh@banana:~$ sudo btrfs balance start / ERROR: error during balancing '/' - No space left on device There may be more info in syslog -

Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-29 Thread Duncan
Marc Haber posted on Sun, 29 Nov 2015 19:06:29 +0100 as excerpted: > Hi Hugo, > > On Sun, Nov 29, 2015 at 02:18:06PM +, Hugo Mills wrote: >> On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote: >>> However, the FAQ >>>

Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

2015-11-29 Thread Imran Geriskovan
On 11/30/15, Duncan <1i5t5.dun...@cox.net> wrote: > Of course you can also try compress-force(=lzo the default > compression so the =spec isn't required), which should give > you slightly better performance than zlib, but also a bit > less efficient compression in terms of size saved. lzo perf