On Tue, Aug 27, 2019 at 03:29:09PM -0500, Eric Sandeen wrote: > On 8/27/19 2:10 PM, dann frazier wrote: > > hey, > > I'm curious if there's a policy about what types of unclean > > shutdowns 'e2fsck -p' can recover, vs. what the kernel will > > automatically recover on mount. We're seeing that unclean shutdowns w/ > > data=journal,journal_csum frequently result in invalid checksums that > > causes the kernel to abort recovery, while 'e2fsck -p' resolves the > > issue non-interactively. > > > > Driver for this question is that some Ubuntu installs set fstab's > > passno=0 for the root fs - which I'm told is based on the assumption > > that both kernel & e2fsck -p have parity when it comes to automatic > > recovery - that's obviously does not appear to be the case - but I > > wanted to confirm whether or not that is by design. > > > > -dann > > Ted or others more involved w/ ext4 will speak w/ authority but it's my > understanding that log replay, whether done by userspace or by the kernel, > should always return the filesystem to a consistent state. If that's not > the case, scripting things so that you grab a qcow-format e2image prior > to fsck so that you can share the problematic image with developers may > help. Thanks Eric. I captured an image in case it's useful: https://people.canonical.com/~dannf/md2.e2ic.qcow2 -dann > > (In XFS land, a large portion of the unreplayable logs we see are the > result of storage that didn't /actually/ persist IOs that it claimed were > persisted prior to the crash/poweroff.) > > -Eric
