Vivaldi corrupts EXT4 file system on opening
-
Hello
Every time I open Vivaldi, the kernel log (dmesg -Tw command) prints these errors:
[sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [sáb nov 30 15:05:24 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0)Then my system fixes these file system bugs created by Vivaldi in the next boot by running fsck command.
I see errors related to file system in the kernel log even when opening the folder of Vivaldi profile with my file manager. I have already cleared the cache and other data of Vivaldi but Vivaldi is still corrupting my EXT4 file system.
Does anyone know a solution?
I don't want to delete the profile of my Vivaldi again to solve this. -
@Strangiato I am not a Linux person, so big spoon of salt, but I doubt this is related to Vivaldi in any way.
OTOH, my guess is that whatever part of the file system Vivaldi is installed in or using, is having some kind of file system issue. That may be some kind of failure issue that requires fsck to be run to repair the system, or (even worse) it may be due to a hardware failure in your diskdrive.
A quick search showed results from 5 hours ago to at least 10 years ago related to your log messages on the first page.
So, my guess, you need to do a repair of the file system.
-
Hello @Strangiato
I think the number 2770363 that appears in the error may be the inode number of the file that may be having the issue. If you run the following command, do you get any pathname showing the path to any file?
sudo debugfs -R 'ncheck 2770363' /dev/sda1
Thanks,
Fred D. -
@Strangiato This is problem with your storage disk. That it affected your Vivaldi profile or install is entirely random. Well, maybe not random. Your Vivaldi profile is somewhere on your disk that you frequently access. You might have more disk corruption, but you won't have noticed it as you have yet to try and access that part of the disk.
You should perform health checks of your disk. SpinRite might be your best option here to evaluate the condition of your disk. If you correct an error and it keeps reappearing, then that is a really bad symptom of a more serious issue.
You should consider replacing the disk.
The Details Guy at Vivaldi.
Do NOT run commands in the browser developer console if you do not understand what the command does! -
@fredallas Here is the output:
sudo debugfs -R 'ncheck 2770363' /dev/sda1 debugfs 1.47.1 (20-May-2024) Inode Pathname 2770363 /home/stalker/.config/vivaldi/Default/DIPS-journal -
@daniel said in Vivaldi corrupts EXT4 file system on opening:
@Strangiato This is problem with your storage disk. That it affected your Vivaldi profile or install is entirely random. Well, maybe not random. Your Vivaldi profile is somewhere on your disk that you frequently access. You might have more disk corruption, but you won't have noticed it as you have yet to try and access that part of the disk.
You should perform health checks of your disk. SpinRite might be your best option here to evaluate the condition of your disk. If you correct an error and it keeps reappearing, then that is a really bad symptom of a more serious issue.
You should consider replacing the disk.
HD Tune and HD Sentinel do not detect any problem. I will try SpinRite.
Thanks. -
@Strangiato
There is a chance the sector of the hard drive that is storing the /home/stalker/.config/vivaldi/Default/DIPS-journal file might be corrupt. Is there a way you may try copying the file somewhere else to see if you can or not copy it? You may try something like: cp /home/stalker/.config/vivaldi/Default/DIPS-journal /tmpYou may also try running the following command which will check the device for bad sectors/blocks. Running the command may take a while depending on the size of the partition plus the speed of the disk: sudo badblocks -v /dev/sda1
If there are bad sectors, you may need to either replace the disk or tell the operating system not to write to the specific sectors that are bad using the e2fsck command or similar. You may need to check that with your specific Linux distribution for proper command/steps.
Regards,
Fred D. -
@fredallas said in Vivaldi corrupts EXT4 file system on opening:
cp /home/stalker/.config/vivaldi/Default/DIPS-journal /tmp
I get an error:
stalker@Arch-PC:~$ ls /home/stalker/.config/vivaldi/Default/DIPS* ls: cannot access '/home/stalker/.config/vivaldi/Default/DIPS-journal': Structure needs cleaning /home/stalker/.config/vivaldi/Default/DIPS stalker@Arch-PC:~$ cp /home/stalker/.config/vivaldi/Default/DIPS-journal /tmp cp: cannot stat '/home/stalker/.config/vivaldi/Default/DIPS-journal': Structure needs cleaning -
@daniel SpinRite found no error after more than 6 hours.
-
@Strangiato Please run:
sudo umount /dev/sda1 sudo fsck -pfv /dev/sda1Or is the system on /dev/sda1? Then this will fail and you need reboot into Linux of a live CD and check there the partition!
-
Yes, my system is installed on /dev/sda1. But I have another Linux distribution installed on another partition created in the same SSD. Here is the output:
$ sudo fsck -pfv /dev/sda1 fsck from util-linux 2.39.3 ARCH: Inode 655927 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 2770363, i_size is 17592186044416, should be 17592186044416. FIXED. ARCH: Inode 6309990 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312174 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312183 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312187 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312189 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312194 extent tree (at level 1) could be narrower. IGNORED. ARCH: Inode 6312198 extent tree (at level 1) could be narrower. IGNORED. 2011221 inodes used (8.77%, out of 22937600) 18150 non-contiguous files (0.9%) 1638 non-contiguous directories (0.1%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 1720443/5610/8 76197307 blocks used (83.05%, out of 91750400) 0 bad blocks 10 large files 1501583 regular files 182172 directories 0 character device files 0 block device files 0 fifos 70520 links 327427 symbolic links (285122 fast symbolic links) 30 sockets ------------ 2081732 filesI am going to reboot and report back soon.
-
After rebooting and then opening Vivaldi, dmesg reported ext4 errors again.
What a bizarre issue...[dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) [dom dez 1 07:48:29 2024] EXT4-fs error (device sda1): ext4_ext_check_inode:524: inode #2770363: comm ThreadPoolForeg: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 1, max 4(4), depth 0(0) -
@Strangiato Try to delete the files named
DIPS*. They have no meaningful purpose in Vivaldi in any case and will be recreated on next browser launch.🎻Volunteer helper · Forum moderator · Sopranos tester 🛠️Troubleshooting 🐛Report a bug 📜Markdown help
🦆"With a rubber duck, one's never alone" -Douglas Adams🦆 -
@Strangiato does
stat /home/stalker/.config/vivaldi/Default/DIPS-journalstill give a usable output?
I might be off the rails here, but at least in the ext4 documentation
i_sizeshould relate to the file size in bytes.And (exactly) 16TiB would be strange file size.
-
@Pathduck said in Vivaldi corrupts EXT4 file system on opening:
@Strangiato Try to delete the files named
DIPS*. They have no meaningful purpose in Vivaldi in any case and will be recreated on next browser launch.Cannot remove them:
$ rm /home/stalker/.config/vivaldi/Default/DIPS* rm: cannot remove '/home/stalker/.config/vivaldi/Default/DIPS-journal': Structure needs cleaning -
@becm said in Vivaldi corrupts EXT4 file system on opening:
stat /home/stalker/.config/vivaldi/Default/DIPS-journal
Here is the output:
$ stat /home/stalker/.config/vivaldi/Default/DIPS-journal stat: cannot statx '/home/stalker/.config/vivaldi/Default/DIPS-journal': Structure needs cleaning -
@Strangiato what's a little bit troubling to me in the
fsckoutput is the message
I found this stupid/wrong number and "fixed" it to exact same value.And even basic tools are unable to touch it due to file metadata still being broken.
-
@Strangiato you could use
debugfsto try and recover (or massively worsen) this sketchy file system state on a lower level.You are advised to already have working backups.
If you do something bad at this level, the whole system can be gone.Better first see if
statis working without problems inside the debug session before trying tormthe invalid file/inode. -
Well, I have no storage device with enough capacity to store all my data.
I have renamed the folder /home/stalker/.config/vivaldi/
and now I'm using a new Vivaldi profile. Unfortunately, this seems the only solution to stop the fsck before every boot after using Vivaldi.Thank you all for the help.
-
@Strangiato so a dirty file system state is not triggered if the broken file is never touched after
fscklies about having repaired it.
possible root cause:
Normally in most states,
DIPS-journalis just a 0 byte file.
A random single bit flip (RAM, Disk, anything in between) may have set the file size to an (arbitrary) high number (2^44).I could observe such an effect on a disk/system during massive Git repository imports which do a checksum on data content (only reason this was noticed at all!)
And after that, there was the (ir)regular Bluescreen twice a week.Tests on RAM and disk did not report anything wrong!
So maybe expect (or at least be not surprised) on degrading system reliability in the near future.
observed effect:
Since EXT4 has checksums for metadata (at least), it detects the inconsistency and marks the files system as dirty.
It seems its "repair" tool is able to determine but not perform the proper fix.
Next logical step; look for a bug/problem ine2fscksource code.
