you can see if anything in debugfs will help. That's part of e2fstools I
think.
In particular, you could use freei to free the inode for this directory
(although I suspect another fsck will then attach it back to lost and
found but I'm not sure)
N.B. Actions like this are last resort and you really do need a backup
before you start.
You might also be able to clear the checksum feature, delete this
directory and then turn it back on.
You can also try rmdir from debugfs.
FWIW, here's a command I use in a testcase to ensure that the first
block of a file on disk is not all zeros:
debugfs -w -R "zap_block -f uninit -p 0x5a 0" "$SRC_LOOPDEV"
That isn't any use to you but gives an example of how debugfs can be
used to modify a filesystem bypassing normal
inode_dump might also help you.
I'm assuming you just want to delete this directory, not save whatever
was in it - if you do want to save whatever was in it then dump here;
https://sourceforge.net/projects/dump/ might do it for you - but use the
latest version from sourceforge, not the version in debian stable.
(I've recently taken over as the maintainer but unfortunately the code
had rotted badly and the versions in debian stable do not understand
some common ext4 features)
(I can provide a deb if you don't want to build from source - if you
want a random deb from a random person on the internet...)
Tim.
On Wed, 11 Dec 2024, Gregor Zattler wrote:
Hi,
* Gregor Zattler <telegr...@gmx.net> [2024-12-09; 01:54 +01]:
Dear debian enthusiasts, I use
rdiff-backup, which now is not able to
work with my most precious backup,
instead throws a python backtrace which
contains:
OSError: [Errno 117] Structure needs cleaning:
b'/mnt/mic-backup/rdiff-backup/durable/rdiff-backup-data/increments/home/grfz/.procmail/backup-post-mailmunge/new'
While a fsck.ext4 -vvvtfDfy on that file
system gives
Failed to optimize directory
/rdiff-backup/durable/rdiff-backup-data/increments/home/grfz/.procmail/backup-post-mailmunge/new
(498074110): Directory block does not have space for checksum
in Pass 3A: Optimizing directories.
Because of
https://blogs.oracle.com/linux/post/space-management-with-large-directories-in-ext4
I tried to copy said directory:
cp -a new neu
this too does not work:
cp: cannot access 'new': Structure needs cleaning
cp: preserving times for 'neu': Read-only file system
Any ideas how to repair said directory,
clean the structure, or another work
around to at least get rdiff-backup get
to use the backup again for restoring?
Or where to ask? The ext3-users
mailing list does not exist any more?
Or how to avoid such a problem next time?
this directory in question is really
huge:
ls -Altr
[...]
-rwx-----x 1 grfz grfz 0 Nov 21 01:26
new.2024-11-21T01:32:48+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 21 16:37
tmp.2024-11-21T16:42:36+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 21 16:37
new.2024-11-21T16:42:36+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 21 23:12
tmp.2024-11-21T23:36:57+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 21 23:12
new.2024-11-21T23:36:57+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 23 01:01
tmp.2024-11-23T01:25:22+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 23 01:01
new.2024-11-23T01:25:22+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 25 00:41
tmp.2024-11-25T00:44:07+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 25 00:41
new.2024-11-25T00:44:07+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 25 15:54
tmp.2024-11-25T15:56:34+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 25 15:54
new.2024-11-25T15:56:34+01:00.dir
-rwx------ 1 grfz grfz 0 Nov 26 00:27
tmp.2024-11-26T00:50:56+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 26 00:27
new.2024-11-26T00:50:56+01:00.dir
-rwx-----x 1 grfz grfz 0 Nov 28 01:06
new.2024-11-28T01:34:32+01:00.dir
drwx------ 2 root root 2139340800 Nov 28 01:37 new
I tried to move the files in the
directory to another one, but this gives
mv: cannot stat FILENAME: Bad message
So I cannot stat, mv, cp, cat these
files or at least some of them.
dmesg shows 35 lines like this
one:
ext4_dirblock_csum_verify:405: inode #498074110: comm ls: No space for
directory leaf checksum. Please run e2fsck -D
and this one:
[76268.580904] EXT4-fs error (device dm-6): ext4_readdir:218: inode #498074110:
comm ls: path (unknown): directory fails checksum at offset 0
But fsck -fDy does not help (as stated
in quoted part, above).
After fsck.ext4 -vvvtfDfy a fsck without
any options tells me the fs is clean.
Any ideas, pointers?
Ciao; Gregor
--
-... --- .-. . -.. ..--.. ...-.-
