Re: Btrfs progs release 6.6.1

[Joe Salmeri <jmscdba@gmail.com>]

On 11/9/23 09:38, David Sterba wrote:
> On Sun, Nov 05, 2023 at 06:40:45PM -0500, Joe Salmeri wrote:
>> Is there a way for btrfs to remove that directory entry which points to
>> the inode that does not exist ?
>>
>> After I removed all the @home snapshots, that got rid of all of them
>> items that btrfs check reports EXCEPT for the one in the @home subvolume
>> so deleting a subvolume can remove the items, but I really don't want to
>> have to delete and restore the @home subvolume to fix it.
>>
>> And since then btrfs has created new timeline snapshots for @home so
>> those obviously have the same issue as the ones I deleted but that
>> problem would go away if I can find a way to remove the offending item
>> in the @home subvolume.
>>
>> Is there some way to remove that item ?
>>
>> Running "ls -al /home/denise/.config/skypeforlinux/blob_storage/" also
>> shows that offending item:
>>
>>       drwx------ 1 denise joe-denise   72 Nov  1 22:49 .
>>       drwxr-xr-x 1 denise joe-denise 3.7K Nov  1 20:07 ..
>>       d????????? ? ?      ?             ?            ? 02179466-b671-4313-8fa5-0eb87d716f92
>>
>> I tried removing /home/denise/.config/skypeforlinux/blob_storage/ since
>> that is the folder that contains the
>> i02179466-b671-4313-8fa5-0eb87d716f92 directory item but that fails
>>
>>       rm -rf /home/denise/.config/skypeforlinux/blob_storage/
>> /usr/bin/rm: cannot remove
>> '/home/denise/.config/skypeforlinux/blob_storage/': Directory not empty
> On a mounted filesystem this is not possible, also I'm not sure what
> exactly is the problem there. It looks like the directory entry is valid
> (thus it shows the file name) but the pointer to the inode is either
> damaged (cosmic rays) or the inode is gone for some reason.

It seems to me that the issue is that this directory

	/home/denise/.config/skypeforlinux/blob_storage/

Contains a directory entry for this child directory

	/home/denise/.config/skypeforlinux/blob_storage/02179466-b671-4313-8fa5-0eb87d716f92

which has an inode number of 31996735 based on the btrfs check output

     [4/7] checking fs roots
     root 262 inode 31996735 errors 1, no inode item
         unresolved ref dir 132030 index 769 namelen 36 name 
02179466-b671-4313-8fa5-0eb87d716f92 filetype 2 errors 5, no dir item, 
no inode ref
         unresolved ref dir 132030 index 769 namelen 36 name 
77ef9cd4-0efe-46af-bf7f-47f582851e16 filetype 2 errors 2, no dir index

But that inode does not exist based on "find /home -inum 31996735"

usr/bin/find: 
‘/home/denise/.config/skypeforlinux/blob_storage/02179466-b671-4313-8fa5-0eb87d716f92’: 
No such file or directory

Therefore since the inode does not really exist nothing will allow 
removal of the directory entry for

	/home/denise/.config/skypeforlinux/blob_storage/02179466-b671-4313-8fa5-0eb87d716f92

> The 'btrfs check' should be able to guess what's the extent of the
> dirent/inode desynchronization and remove the entry eventually, but as
> always 'check + repair' should be used with care and when absolutely
> sure that it's not making the things worse. Some cross checks could be
> possible, e.g. look up the relevant data in the tree dump.

I have been reluctant to do btrfs --repair because of all the warnings about how it can make things worse.

I would be nice if it would prompt before doing each repair step, but I have never run it before and suspect it probably does not do that.


-- 
Regards,

Joe