Hello, I''m trying to shrink my Btrfs filesystem to the smallest size it can go, here''s the information: 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 605.98GB path /dev/sda6 Btrfs Btrfs v0.19 Data: total=580.90GB, used=490.88GB System, DUP: total=32.00MB, used=76.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=12.51GB, used=1001.61MB Here''s the command I use to resize: [root@archpc ~]# btrfs file res 500g /home/jordan/Storage/ Resize ''/home/jordan/Storage/'' of ''500g'' ERROR: unable to resize ''/home/jordan/Storage/'' - No space left on device I was wondering if that size doesn''t work then what''s the minimum I can shrink to? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Run "btrfs balance start -musage=1 -dusage=1", and then try it again. This may require update btrfs tools however. On Fri, Nov 2, 2012 at 10:09 PM, Jordan Windsor <jordanw2@gmail.com> wrote:> Hello, > I''m trying to shrink my Btrfs filesystem to the smallest size it can > go, here''s the information: > > 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 605.98GB path /dev/sda6 > > Btrfs Btrfs v0.19 > > Data: total=580.90GB, used=490.88GB > System, DUP: total=32.00MB, used=76.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=12.51GB, used=1001.61MB > > Here''s the command I use to resize: > > [root@archpc ~]# btrfs file res 500g /home/jordan/Storage/ > Resize ''/home/jordan/Storage/'' of ''500g'' > ERROR: unable to resize ''/home/jordan/Storage/'' - No space left on device > > I was wondering if that size doesn''t work then what''s the minimum I > can shrink to? > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, here''s the new output: [root@archpc ~]# btrfs bal start -musage=1 -dusage=1 /home/jordan/Storage/ Done, had to relocate 3 out of 609 chunks [root@archpc ~]# btrfs fi df /home/jordan/Storage/ Data: total=580.88GB, used=490.88GB System, DUP: total=32.00MB, used=76.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=13.01GB, used=1001.83MB [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 Btrfs Btrfs v0.19 [root@archpc ~]# btrfs file res 500g /home/jordan/Storage/ Resize ''/home/jordan/Storage/'' of ''500g'' ERROR: unable to resize ''/home/jordan/Storage/'' - No space left on device Thanks. (Had to resend forgot to CC the mailing list, sorry) On Sat, Nov 3, 2012 at 3:09 PM, Jordan Windsor <jordanw2@gmail.com> wrote:> Hello, > here''s the new output: > > [root@archpc ~]# btrfs bal start -musage=1 -dusage=1 /home/jordan/Storage/ > Done, had to relocate 3 out of 609 chunks > > [root@archpc ~]# btrfs fi df /home/jordan/Storage/ > Data: total=580.88GB, used=490.88GB > System, DUP: total=32.00MB, used=76.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=13.01GB, used=1001.83MB > > [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 > > Btrfs Btrfs v0.19 > > [root@archpc ~]# btrfs file res 500g /home/jordan/Storage/ > Resize ''/home/jordan/Storage/'' of ''500g'' > ERROR: unable to resize ''/home/jordan/Storage/'' - No space left on device > > Thanks. > > On Sat, Nov 3, 2012 at 2:43 PM, cwillu <cwillu@cwillu.com> wrote: >> Run "btrfs balance start -musage=1 -dusage=1", and then try it again. >> This may require update btrfs tools however. >> >> On Fri, Nov 2, 2012 at 10:09 PM, Jordan Windsor <jordanw2@gmail.com> wrote: >>> Hello, >>> I''m trying to shrink my Btrfs filesystem to the smallest size it can >>> go, here''s the information: >>> >>> 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 605.98GB path /dev/sda6 >>> >>> Btrfs Btrfs v0.19 >>> >>> Data: total=580.90GB, used=490.88GB >>> System, DUP: total=32.00MB, used=76.00KB >>> System: total=4.00MB, used=0.00 >>> Metadata, DUP: total=12.51GB, used=1001.61MB >>> >>> Here''s the command I use to resize: >>> >>> [root@archpc ~]# btrfs file res 500g /home/jordan/Storage/ >>> Resize ''/home/jordan/Storage/'' of ''500g'' >>> ERROR: unable to resize ''/home/jordan/Storage/'' - No space left on device >>> >>> I was wondering if that size doesn''t work then what''s the minimum I >>> can shrink to? >>> >>> Thanks. >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.88GBThis 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.83MBIf 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 6, 2012 at 9:45 AM, David Sterba <dave@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). > > davidThanks 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html