* e2fsck fails on non journalled partition
@ 2019-03-15 19:28 Ede Wolf
2019-03-16 2:57 ` Andreas Dilger
0 siblings, 1 reply; 6+ messages in thread
From: Ede Wolf @ 2019-03-15 19:28 UTC (permalink / raw)
To: linux-ext4
I have to check an ext4 partition, that has been created without a
journal. But, as it seems, e2fsck is refusing to check this drive,
failing with a "no external journal has been found" error, code 12. That
of course is correct, no journal does imply no external journal.
I am wondering, ^has_journal is well documented in both the mkfs.ext4
manpage as well as tune2fs. So by omitting the journal nothing obscure,
hacky or obviously unsupported has been done.
Why is e2fsck refusing to check the partition? Or what else may I have
be doing wrong?
~ # e2fsck -fv /dev/sde1
e2fsck 1.44.5 (15-Dec-2018)
Can't find external journal
USERDATA: ********** WARNING: Filesystem still has errors **********
~ # echo $?
12
~ #
Filesystem has been created similar to this:
mkfs -m 0 -O
"^has_journal,dir_index,^metadata_csum,64bit,^ext_attr,^huge_file,large_dir,^metadata_csum_seed,^quota,extent"
-b 4096 -i 32768 -L USERDATA
~ # tune2fs -l /dev/sde1
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name: USERDATA
Last mounted on: /mnt/userdata
Filesystem UUID: 241d6272-a004-44ef-9998-7fbc3ef98672
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 with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4669440
Block count: 9338880
Reserved block count: 0
Overhead blocks: 1536
Free blocks: 5602781
Free inodes: 4247845
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: Fri Mar 15 20:16:26 2019
Last write time: Fri Mar 15 20:16:26 2019
Mount count: 90
Maximum mount count: -1
Last checked: Thu Jan 31 18:49:12 2019
Check interval: 0 (<none>)
Lifetime writes: 204 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
Journal UUID: 00000000-1b00-0000-0000-000000000000
Journal inode: 131072
Default directory hash: half_md4
Directory Hash Seed: 2416ec00-bef9-437a-a3b1-f626303d72a2
FS Error count: 41
First error time: Sun Mar 3 13:15:39 2019
First error function: ext4_readdir
First error line #: 182
First error inode #: 3673403
First error block #: 0
Last error time: Mon Mar 11 18:22:09 2019
Last error function: ext4_empty_dir
Last error line #: 2712
Last error inode #: 639817
Last error block #: 1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: e2fsck fails on non journalled partition
2019-03-15 19:28 e2fsck fails on non journalled partition Ede Wolf
@ 2019-03-16 2:57 ` Andreas Dilger
2019-03-16 9:10 ` Ede Wolf
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Dilger @ 2019-03-16 2:57 UTC (permalink / raw)
To: listac; +Cc: linux-ext4
It looks like you have some superblock corruption, since the journal UUID is non-zero, and the journal inode is also non-zero. You can probably use debugfs "ssv" command to clear these fields so that e2fsck doesn't think there is a journal somewhere.
Cheers, Andreas
> On Mar 15, 2019, at 13:28, Ede Wolf <listac@nebelschwaden.de> wrote:
>
> I have to check an ext4 partition, that has been created without a journal. But, as it seems, e2fsck is refusing to check this drive, failing with a "no external journal has been found" error, code 12. That of course is correct, no journal does imply no external journal.
>
> I am wondering, ^has_journal is well documented in both the mkfs.ext4 manpage as well as tune2fs. So by omitting the journal nothing obscure, hacky or obviously unsupported has been done.
>
> Why is e2fsck refusing to check the partition? Or what else may I have be doing wrong?
>
>
> ~ # e2fsck -fv /dev/sde1
> e2fsck 1.44.5 (15-Dec-2018)
> Can't find external journal
>
> USERDATA: ********** WARNING: Filesystem still has errors **********
>
> ~ # echo $?
> 12
> ~ #
>
> Filesystem has been created similar to this:
>
> mkfs -m 0 -O "^has_journal,dir_index,^metadata_csum,64bit,^ext_attr,^huge_file,large_dir,^metadata_csum_seed,^quota,extent" -b 4096 -i 32768 -L USERDATA
>
>
>
> ~ # tune2fs -l /dev/sde1
> tune2fs 1.44.5 (15-Dec-2018)
> Filesystem volume name: USERDATA
> Last mounted on: /mnt/userdata
> Filesystem UUID: 241d6272-a004-44ef-9998-7fbc3ef98672
> 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 with errors
> Errors behavior: Continue
> Filesystem OS type: Linux
> Inode count: 4669440
> Block count: 9338880
> Reserved block count: 0
> Overhead blocks: 1536
> Free blocks: 5602781
> Free inodes: 4247845
> 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: Fri Mar 15 20:16:26 2019
> Last write time: Fri Mar 15 20:16:26 2019
> Mount count: 90
> Maximum mount count: -1
> Last checked: Thu Jan 31 18:49:12 2019
> Check interval: 0 (<none>)
> Lifetime writes: 204 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
> Journal UUID: 00000000-1b00-0000-0000-000000000000
> Journal inode: 131072
> Default directory hash: half_md4
> Directory Hash Seed: 2416ec00-bef9-437a-a3b1-f626303d72a2
> FS Error count: 41
> First error time: Sun Mar 3 13:15:39 2019
> First error function: ext4_readdir
> First error line #: 182
> First error inode #: 3673403
> First error block #: 0
> Last error time: Mon Mar 11 18:22:09 2019
> Last error function: ext4_empty_dir
> Last error line #: 2712
> Last error inode #: 639817
> Last error block #: 1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: e2fsck fails on non journalled partition
2019-03-16 2:57 ` Andreas Dilger
@ 2019-03-16 9:10 ` Ede Wolf
2019-03-17 21:53 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: Ede Wolf @ 2019-03-16 9:10 UTC (permalink / raw)
To: linux-ext4
Thanks very, very much. That "ssv" did the trick!
Learned something new and the next beer of course is on you.
Ede
Am 16.03.19 um 03:57 schrieb Andreas Dilger:
> It looks like you have some superblock corruption, since the journal UUID is non-zero, and the journal inode is also non-zero. You can probably use debugfs "ssv" command to clear these fields so that e2fsck doesn't think there is a journal somewhere.
>
> Cheers, Andreas
>
>> On Mar 15, 2019, at 13:28, Ede Wolf <listac@nebelschwaden.de> wrote:
>>
>> I have to check an ext4 partition, that has been created without a journal. But, as it seems, e2fsck is refusing to check this drive, failing with a "no external journal has been found" error, code 12. That of course is correct, no journal does imply no external journal.
>>
>> I am wondering, ^has_journal is well documented in both the mkfs.ext4 manpage as well as tune2fs. So by omitting the journal nothing obscure, hacky or obviously unsupported has been done.
>>
>> Why is e2fsck refusing to check the partition? Or what else may I have be doing wrong?
>>
>>
>> ~ # e2fsck -fv /dev/sde1
>> e2fsck 1.44.5 (15-Dec-2018)
>> Can't find external journal
>>
>> USERDATA: ********** WARNING: Filesystem still has errors **********
>>
>> ~ # echo $?
>> 12
>> ~ #
>>
>> Filesystem has been created similar to this:
>>
>> mkfs -m 0 -O "^has_journal,dir_index,^metadata_csum,64bit,^ext_attr,^huge_file,large_dir,^metadata_csum_seed,^quota,extent" -b 4096 -i 32768 -L USERDATA
>>
>>
>>
>> ~ # tune2fs -l /dev/sde1
>> tune2fs 1.44.5 (15-Dec-2018)
>> Filesystem volume name: USERDATA
>> Last mounted on: /mnt/userdata
>> Filesystem UUID: 241d6272-a004-44ef-9998-7fbc3ef98672
>> 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 with errors
>> Errors behavior: Continue
>> Filesystem OS type: Linux
>> Inode count: 4669440
>> Block count: 9338880
>> Reserved block count: 0
>> Overhead blocks: 1536
>> Free blocks: 5602781
>> Free inodes: 4247845
>> 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: Fri Mar 15 20:16:26 2019
>> Last write time: Fri Mar 15 20:16:26 2019
>> Mount count: 90
>> Maximum mount count: -1
>> Last checked: Thu Jan 31 18:49:12 2019
>> Check interval: 0 (<none>)
>> Lifetime writes: 204 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
>> Journal UUID: 00000000-1b00-0000-0000-000000000000
>> Journal inode: 131072
>> Default directory hash: half_md4
>> Directory Hash Seed: 2416ec00-bef9-437a-a3b1-f626303d72a2
>> FS Error count: 41
>> First error time: Sun Mar 3 13:15:39 2019
>> First error function: ext4_readdir
>> First error line #: 182
>> First error inode #: 3673403
>> First error block #: 0
>> Last error time: Mon Mar 11 18:22:09 2019
>> Last error function: ext4_empty_dir
>> Last error line #: 2712
>> Last error inode #: 639817
>> Last error block #: 1
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: e2fsck fails on non journalled partition
2019-03-16 9:10 ` Ede Wolf
@ 2019-03-17 21:53 ` Theodore Ts'o
2019-03-17 22:51 ` Ede Wolf
0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2019-03-17 21:53 UTC (permalink / raw)
To: Ede Wolf; +Cc: linux-ext4
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.)
I'm still really wondering how this could have happened, though...
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: e2fsck fails on non journalled partition
2019-03-17 21:53 ` Theodore Ts'o
@ 2019-03-17 22:51 ` Ede Wolf
2019-03-18 14:35 ` Ede Wolf
0 siblings, 1 reply; 6+ messages in thread
From: Ede Wolf @ 2019-03-17 22:51 UTC (permalink / raw)
To: linux-ext4
> 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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: e2fsck fails on non journalled partition
2019-03-17 22:51 ` Ede Wolf
@ 2019-03-18 14:35 ` Ede Wolf
0 siblings, 0 replies; 6+ messages in thread
From: Ede Wolf @ 2019-03-18 14:35 UTC (permalink / raw)
To: linux-ext4
> Further, currently after each mount tune2fs reports a "not clean"
> Filesystem state.
My bad, this is of course just the indicator wether the drive has been
unmouted cleanly or not. I've messed this up with the other message
saying something like "48 error have occured since last check"
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-18 14:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-15 19:28 e2fsck fails on non journalled partition Ede Wolf
2019-03-16 2:57 ` Andreas Dilger
2019-03-16 9:10 ` Ede Wolf
2019-03-17 21:53 ` Theodore Ts'o
2019-03-17 22:51 ` Ede Wolf
2019-03-18 14:35 ` Ede Wolf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox