Re: fsck fails to check?
Quoting Ralph Katz (ralph.katz@rcn.com):
> On 07/23/2015 12:59 PM, David Wright wrote:
>
> > Yes, you missed yesterday's posting:
> >
> > https://lists.debian.org/debian-user/2015/07/msg00977.html
>
> I saw it, but perhaps I don't understand it.
>
> From man tune2fs:
>
> > -i interval-between-checks[d|m|w]
> > Adjust the maximal time between two filesystem checks. No suf‐
> > fix or d will interpret the number interval-between-checks as
> > days, m as months, and w as weeks. A value of zero will disable
> > the time-dependent checking.
> >
> > It is strongly recommended that either -c (mount-count-depen‐
> > dent) or -i (time-dependent) checking be enabled to force peri‐
> > odic full e2fsck(8) checking of the filesystem. Failure to do
> > so may lead to filesystem corruption (due to bad disks, cables,
> > memory, or kernel bugs) going unnoticed, ultimately resulting in
> > data loss or corruption.
>
> So I assumed setting the time interval would force a check on the next
> reboot. syslog shows check not done:
>
> Jul 23 10:45:49 spike2 kernel: [ 9.194139] EXT4-fs (sda1): warning:
> checktime reached, running e2fsck is recommended
>
> But ~$ cat /run/initramfs/fsck.log (which ran before the syslog entry)
> Log of fsck -a -t ext4 /dev/sda1
> Thu Jul 23 14:45:29 2015
>
> fsck from util-linux 2.25.2
> /dev/sda1: clean, 182790/7069696 files, 7971750/28261376 blocks
>
> Thu Jul 23 14:45:30 2015
> ----------------
>
> And again, from tune2fs -l /dev/sda1
> Last mount time: Thu Jul 23 10:45:36 2015
> Last checked: Mon May 12 14:08:09 2014
>
> So the question is, how to set a time interval that actually forces a
> check as suggested my man tune2fs quoted above? Or is this a bug?
You and I thought the same thing. Looking at Jape's -c 1 (which
has to be reversed after the fsck) and the manpage suggested that
the following command would be ideal:
# tune2fs -c 0 -i 365 -T 20101010 /dev/sdDN (repeated for each partition)
This should set up an fsck but with no automatic repetition for a
year, it's easily scripted, would work with remote access (no need to
talk to grub) and even if you boot into a different installation/
partition.
But it doesn't work. A bug is already reported:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792752
but it doesn't make it unambiguous that -i expiry doesn't work,
though it implies as much.
Cheers,
David.
Reply to: