* 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[parent not found: <aa605999-708c-4b8c-a05c-78fd2cc6b5b2@gmail.com>]
* 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