On Tue, Nov 6, 2012 at 9:45 AM, David Sterba <d...@jikos.cz> wrote: > On Sat, Nov 03, 2012 at 03:10:52PM +1030, Jordan Windsor wrote: >> [root@archpc ~]# btrfs fi df /home/jordan/Storage/ >> Data: total=580.88GB, used=490.88GB > > This is getting full, 84%, there is not much chance of getting rid of > substantially many 1G-chunks through the 'usage=1' balance filter. > Some of the space between 490G and 580G will be spent on slack space and > fragmentation, the rest may be packed together by a higher usage= value > (but will be slower due to relocating more data). > >> System, DUP: total=32.00MB, used=76.00KB >> System: total=4.00MB, used=0.00 >> Metadata, DUP: total=13.01GB, used=1001.83MB > > If you intend to shrink a filesystem, all space group types must be > taken into account, so here you have at least > > 580G + 2x32M + 4M + 2x13G = ~607G > >> [root@archpc ~]# btrfs fi sh >> failed to read /dev/sr0 >> Label: 'Storage' uuid: 717d4a43-38b3-495f-841b-d223068584de >> Total devices 1 FS bytes used 491.86GB >> devid 1 size 612.04GB used 606.96GB path /dev/sda6 > ^^^^^^ > confirmed :) > > So basically you cannot go under this number when shrinking. I think you > can squeeze the metadata space down to 2G (or maybe to 1G, it's getting > very close to 1G so hard to guess) by the -musage= filter AND using at > least 3.7 kernel (or 3.6+ chris' for-linus branch) with the fixed > over-allocation bug (otherwise the size will stay pinned at 2% of the > filesystem size). > > david
Thanks for the info! Shame I can't save space though. Thanks anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
