Linux Btrfs filesystem development
 help / color / mirror / Atom feed
* Btrfs progs release 6.6.1
@ 2023-11-05 22:20 David Sterba
       [not found] ` <aa605999-708c-4b8c-a05c-78fd2cc6b5b2@gmail.com>
  0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2023-11-05 22:20 UTC (permalink / raw)
  To: linux-btrfs

Hi,

btrfs-progs version 6.6.1 have been released. This is an important bugfix release,
v6.6 is broken and should not be used.

Due to an accidental change in definition of the scanning ioctl in a
"documentation only" patch the mkfs or 'device scan' command were not able to
register all devices and mounting multi-device filesystems failed.
I misdiagnosed that as a change in the CI environment, thanks all early
packagers and testers for reports and the fix.

Changelog:

* fix device scanning ioctl definition, accidental change to the 'forget' ioctl
  that breaks mounting multi-device filesystems

Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
Release: https://github.com/kdave/btrfs-progs/releases/tag/v6.6.1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Btrfs progs release 6.6.1
       [not found] ` <aa605999-708c-4b8c-a05c-78fd2cc6b5b2@gmail.com>
@ 2023-11-05 23:40   ` Joe Salmeri
  2023-11-09 14:38     ` David Sterba
  0 siblings, 1 reply; 4+ messages in thread
From: Joe Salmeri @ 2023-11-05 23:40 UTC (permalink / raw)
  To: David Sterba, linux-btrfs

Hi David,

Thanks for the info.

I'm using btrfsprogs 6.5.1-1.2 and my btrfs filesystem is a single 
partition on a single device so it does not seem like the bugfix release 
is related to my issue.

I actually think the issue occurred because of Skype crashing ( although 
it does still seem a little odd to me that would cause the issue ).

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

Joe

> On 11/5/23 17:20, David Sterba wrote:
>> Hi,
>>
>> btrfs-progs version 6.6.1 have been released. This is an important bugfix release,
>> v6.6 is broken and should not be used.
>>
>> Due to an accidental change in definition of the scanning ioctl in a
>> "documentation only" patch the mkfs or 'device scan' command were not able to
>> register all devices and mounting multi-device filesystems failed.
>> I misdiagnosed that as a change in the CI environment, thanks all early
>> packagers and testers for reports and the fix.
>>
>> Changelog:
>>
>> * fix device scanning ioctl definition, accidental change to the 'forget' ioctl
>>    that breaks mounting multi-device filesystems
>>
>> Tarballs:https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
>> Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
>> Release:https://github.com/kdave/btrfs-progs/releases/tag/v6.6.1
> -- 
> Regards,
>
> Joe

-- 
Regards,

Joe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Btrfs progs release 6.6.1
  2023-11-05 23:40   ` Joe Salmeri
@ 2023-11-09 14:38     ` David Sterba
  2023-11-10 15:46       ` Joe Salmeri
  0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2023-11-09 14:38 UTC (permalink / raw)
  To: Joe Salmeri; +Cc: David Sterba, linux-btrfs

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.

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Btrfs progs release 6.6.1
  2023-11-09 14:38     ` David Sterba
@ 2023-11-10 15:46       ` Joe Salmeri
  0 siblings, 0 replies; 4+ messages in thread
From: Joe Salmeri @ 2023-11-10 15:46 UTC (permalink / raw)
  To: dsterba; +Cc: David Sterba, linux-btrfs

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-11-10 15:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-05 22:20 Btrfs progs release 6.6.1 David Sterba
     [not found] ` <aa605999-708c-4b8c-a05c-78fd2cc6b5b2@gmail.com>
2023-11-05 23:40   ` Joe Salmeri
2023-11-09 14:38     ` David Sterba
2023-11-10 15:46       ` Joe Salmeri

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox