On 2018/11/12 下午1:30, Anand Jain wrote: [snip] >>>> Btrfs-progs could do it with some extra dirty work. >>>> (I purposed offline device resize idea, but didn't implement it yet) >>>> >>>> You could use this branch: >>>> https://github.com/adam900710/btrfs-progs/tree/dirty_fix >>> >>> Qu, >>> >>> The online resize should work here right? >> >> Nope, the user reported unable to mount RW, due to exhausted metadata >> space. >> >> And due to the failure of RW mount, reported can't do online resize, >> thus we need to do offline one. > > Its nice tool fixed the issue here, but in the long term we need > a way to free some space IMO. Totally agree we should fix the problem in a proper way. > > Source of the problem is unable to mount RW when metadata space is > full. A serious issue. In my opinion, it's a problem that we shouldn't allow such relocation, return ENOSPC earlier, other than allowing such relocation and cause ENOSPC half way. It may be related to global reservation, but I'm not completely sure. Anyway, it's not something we can easily debug on the reporter's fs, so I went the easier way to help the user. Thanks, Qu > > Adding more disk space was viable workaround at this use case, which > might not be true in all use cases. Like user may just want to mount > and free some space. > > I think we need to fine tune the reserve space usage like distinguish > the reserve space allocation between the new metadata item VS > modification of the old metadata items. And reserve a space for > the modification of the metadata, so that mount and freeing of > some files will work. > > Thanks, Anand > > >> Thanks, >> Qu >> >>> >>> Thanks, Anand >>> >>> >>>> It's a quick and dirty fix to allow "btrfs-corrupt-block -X >>>> <device>" to >>>> extent device size to max. >>>> >>>> Please try above command to see if it solves your problem. >>>> >>>> Thanks, >>>> Qu >>>> >>>>> >>>>> I hope someone can help me out with this. >>>>> Thanks! >>>>> >>>> >>
Attachment:
signature.asc
Description: OpenPGP digital signature
