On Wed, Nov 20, 2019, 11:58 PM Belisko Marek <marek.belisko@xxxxxxxxx> wrote:
On Thu, Nov 21, 2019 at 7:25 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Nov 12, 2019 at 3:52 AM Belisko Marek <marek.belisko@xxxxxxxxx> wrote:
> >
> > On Mon, Nov 11, 2019 at 4:47 PM Lennart Poettering
> > <lennart@xxxxxxxxxxxxxx> wrote:
> > >
> > > On Mo, 11.11.19 13:33, Belisko Marek (marek.belisko@xxxxxxxxx) wrote:
> > > 65;5802;1c
> > > > Hi,
> > > >
> > > > I'm using systemd 234 (build by yocto) and I've setup automount of
> > > > sdcard in fstab. This works perfectly fine. But I have seen from time
> > > > to time when system goes to emergency mode because sdcard filesystem
> > > > (ext4) have an issue and cannot be mounted. I was thinking about
> > > > forcing fsck for every boot. Reading manual it should be enough to set
> > > > passno (6th column in fstab) to anything higher then 0. I set ti to 2
> > > > but inspecting logs it doesn't seems fsck is performed. Am I still
> > > > missing something? Thanks.
> > >
> > > Well, note that ext4's fsck only does an actual file system check
> > > every now and then. Hence: how did you determine fsck wasn't started?
> > >
> > > Do you see the relevant fsck in "systemctl -t service | grep
> > > systemd-fsck@"?
> > I just saw in log:
> > [ OK ] Found device /dev/mmcblk1p1.
> > Mounting /mnt/sdcard...
> > [ 8.339072] EXT4-fs (mmcblk1p1): VFS: Found ext4 filesystem with
> > invalid superblock checksum. Run e2fsck?
> > [FAILED] Failed to mount /mnt/sdcard.
>
> This isn't normal. Your effort should be on finding out why this
> problem is happening in the first place. This doesn't strike me as the
> (somewhat) ordinary case of unclean unmount, which results in journal
> replay at next mount attempt. But something considerably more serious.
Problem is it's very hard to reproduce and this is not rootfs just
external SDcard for storing some data.
If I hit this system goes to emergency mode and device is dead and I
would like to prevent that in first place.
IMO fsck should help to recover this issue and should continue without
issues. Thanks.
Possibly adding nofail option in fstab will prevent startup from going into rescue.target.
I'm skeptical of unattended use of fsck. That's what journal replay is for, and if replay can't fix the problem, then the underlying problem needs to be fixed rather than papered over with fsck.
You might consider testing this SDCard with f3, which will check for corruption, and fake flash. Reformat, mount, f3write /mountpoint, f3read /mountpoint.
I don't trust consumer SDCards for anything. I've had name brand stuff fail.
The systemd journal should show evidence of either umount success or failure for this SDCard on restart or shutdown. Do the corruptions only happen on shutdowns? It both shutdown and restart? SDCards can get really fussy, exhibiting corruptions, or just brick themselves, when power is removed while writes are still happening internally. Cheaper flash may be slower to flush to stable media. You can give it more time by manually unmounting this SDCard before reboot or shutdown.
Chris Murphy
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
