* 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