lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 17 Mar 2019 23:51:28 +0100 From: Ede Wolf <listac@...elschwaden.de> To: linux-ext4@...r.kernel.org Subject: Re: e2fsck fails on non journalled partition > I'm still really wondering how this could have happened, though... Not sure wether this is an explanation, but I suspect the SSD to be in a dying state. It's really old (5 years at least, probably even more) and has been used for tempfiles and caching for at least the last 3 years, so it has seen quite a bit of IO by now. Further, currently after each mount tune2fs reports a "not clean" Filesystem state. I can fsck it all I want, mount it and after not too long time the state changes from clean. Smartctl however logs no errors so far. But, the journal inode and UUID are still at zero - or non existing - and it mounts cleanly even with a unclean state: EXT4-fs (sdd1): mounted filesystem without journal. Opts: noacl In case it helps, one more tune2fs output, otherwise sorry for the noise: tune2fs 1.44.5 (15-Dec-2018) Filesystem volume name: USERDATA Last mounted on: /mnt/userdata Filesystem UUID: 241d6272-a004-44ef-9998-7fbc3ef98972 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype extent 64bit large_dir sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 4669440 Block count: 9338880 Reserved block count: 0 Overhead blocks: 1536 Free blocks: 5576918 Free inodes: 4246457 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 1024 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 1024 Filesystem created: Wed Jan 30 18:42:35 2019 Last mount time: Sun Mar 17 15:08:30 2019 Last write time: Sun Mar 17 15:08:30 2019 Mount count: 2 Maximum mount count: -1 Last checked: Sun Mar 17 01:17:43 2019 Check interval: 0 (<none>) Lifetime writes: 206 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Default directory hash: half_md4 Directory Hash Seed: 2416ec00-bef9-437a-a3b1-f626303d72a2 However, I am quite thankful that the kernel has let me mount this drive until the issue was resolved. And I am aware I can remove the noacl option from fstab. Thanks again. Ede Am 17.03.19 um 22:53 schrieb Theodore Ts'o: > I'm really curious how the superblock got into this configuration: > >>>> ~ # tune2fs -l /dev/sde1 >>>> tune2fs 1.44.5 (15-Dec-2018) >>>> Filesystem volume name: USERDATA > ... >>>> Filesystem features: ext_attr resize_inode dir_index filetype extent 64bit large_dir sparse_super large_file > > There is no journal features here at all > >>>> Journal UUID: 00000000-1b00-0000-0000-000000000000 >>>> Journal inode: 131072 > > A journal UUID and inode should never be set at the same time. But > this is a lot more than a single bit flip. The rest of the sueprblock > looks sane, so it's not a matter of someone writing garbage over the > on-disk copy. > > Maybe a wild pointer smashing two bytes in the middle of the > superblock? > > In any case, this is something where we should probably add sanity > checks so kernel will refuse to mount a file system like this --- and > e2fsck should also try to see if the backup superblock is sane and try > using it. (We could also teach e2fsck to offer to clear these fields so > a user won't have to use debugfs's ssv command if falling back to > backup superblock doesn't work.) > > > - Ted > >
Powered by blists - more mailing lists