I have been working on setting up some methodologies for creating system backups and archives of the work I want to do with Charlie - and I have been experimenting with creating and compressing disk, (SD card), images.
During the process of creating the images, I have been loop-mounting the images and fsck’ing1 them to make sure that the file-system hasn’t been damaged during the wash-dry-fold cycles developing my techniques.
Taking a look at the filesystem using tune2fs - I noticed some interesting things:
root@Charlie:/home/pi# tune2fs -l /dev/mmcblk0p2 tune2fs 1.44.5 (15-Dec-2018) Filesystem volume name: rootfs Last mounted on: / Filesystem UUID: 24eaa08b-10f2-49e0-8283-359f7eb1a0b6 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3853200 Block count: 15563776 Reserved block count: 480503 Free blocks: 14167650 Free inodes: 3709149 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 910 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8112 Inode blocks per group: 507 Flex block group size: 16 Filesystem created: Tue Nov 5 23:57:39 2019 Last mount time: Thu Feb 14 13:12:11 2019 Last write time: Thu Feb 14 13:11:59 2019 Mount count: 1 Maximum mount count: -1 Last checked: Thu Feb 14 13:11:59 2019 Check interval: 0 (<none>) Lifetime writes: 35 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 inode: 8 First orphan inode: 267571 Default directory hash: half_md4 Directory Hash Seed: 2525e02c-083e-4713-9d57-e4a4d6af7b0e Journal backup: inode blocks Checksum type: crc32c Checksum: 0xac5e9886
- The filesystem error “errors behavior” is set to “continue”
- The “Maximum mount count” (before requiring a disk check) is set to “-1” - disabled.
- The “Check interval” (elapsed time before requiring a disk check) is set to “0” - disabled.
- (Interesting maybe?) The last time the filesystem was checked for consistency was back on Valentine’s day, 2019! (or so the filesystem thinks. . . .)
The tune2fs man page says this about mount-count and interval dependent disk checking:
Though most distributions ship with filesystems set up to NEVER check, (and, just maybe, there’s a good reason for this), I would think that a system like the Dexter robots would want to include some kind of periodic, forced, filesystem sanity check.
When I install a Linux desktop/server system, I set my systems up to do the following:
- The filesystem error behavior mode is set to “re-mount read-only”
- The filesystem force-check interval is set to about a month - actually an odd number of days so the fsck-on-reboot doesn’t always happen on Monday. ()
- The filesystem force-check mount count is set to about twenty-or-so reboots/remounts, so that about once a month a frequently used system will ask for a disk check.
In Charlie’s case, I set a more aggressive schedule:
root@Charlie:/home/pi# tune2fs -e remount-ro -i 17 -c 5 -C 6 /dev/mmcblk0p2 tune2fs 1.44.5 (15-Dec-2018) Setting maximal mount count to 5 [<== Check Charlies file-system every fifth reboot.] Setting current mount count to 6 [<== start checking and reset at the next reboot.] Setting error behavior to 2 [<== remount read-only if the filesystem prangs to limit the damage.] Setting interval between checks to 1468800 seconds [<== force a re-check every 17 days if it doesn't happen sooner.]
My thinking is that a system like Charlie - or maybe Carl? - is more likely to have “interesting” things happen to it than the typical sits-and-plays-Solitare desktop system. As a consequence, having a system that is more vigilant about disk integrity checking is a Good Thing.
Are there any really good reasons NOT to set up, (at the very least), some kind of periodic integrity test on our 'bots?
 fsck - to run the e2fsck utility which checks a Linux ext2/3/4 filesystem for errors.