EasyOS clean shutdown and SSD TRIM

I posted recently about the ext4 working-partition not shutting down cleanly:

https://bkhome.org/news/202002/working-partition-ext4-filesystem-shuts-down-unclean.html

What happens is that if the working-partition is examined after shutdown, 'fsck.ext4' reports "was not cleanly unmounted".

I recall this being a problem with the puppies, but perhaps only with certain PUPMODEs -- don't recall exactly. EasyOS has this problem, although it has never caused any actual fault.

For a couple of days, I worked on an idea, at bootup to keep the initramfs running, instead of performing a 'switch_root', do a 'chroot' onto the aufs layered filesystem. Then at shutdown can do a 'exit' back to the initramfs, and then aufs can be unmounted. Or something like that -- I experimented with various related ideas. But still could not get aufs to unmount.

ext4 journal

Then I made a discovery. With the EasyOS USB-sticks, the ext4 working-partition has the journal disabled. This is done to prolong the life of the USB-stick, and I also advised disabling the journal if doing a frugal install to a SSD. The discovery, is that if the journal is enabled, it unmounts cleanly.

I read here and there on the Internet, the general consensus is that protection of integrity of the ext4 filesystem is worth it, even if the lifetime of the solid-state drive is reduced. The argument is that SSDs last for years anyway. Dunno about cheap Flash sticks though, as they have much simpler control circuitry.

Have decided to go for journal enabled.

TRIM

SSD performance may be improved if unused inodes are released. This can be achieved by mounting with the "discard" option, for example "mount -t ext4 -o discard /dev/sdb1 /mnt/sdb1", or by periodically running the 'fstrim' utility on a mounted partition, for example "fstrim /mnt/sdb1" -- you use one or the other, not both.

However, apparently SSDs work OK without this trim intervention, especially fairly recent and more intelligent ones. There may be some slow-down though, that trim intervention my improve.

I decided to give it a go. In the 'init' script in the initrd, there is now this code:

###execute TRIM on ssd###
TRIMflg=''
if [ "$WKG_FS" == "ext4" ];then #200302
 HDDflg="$(cat /sys/block/${WKG_DRV}/queue/rotational)"
 if [ "$HDDflg" == "0" ];then #0 it is an SSD
  #unfortunately, busybox hdparm will only read ata drives, not usb...
  TRIMflg="$(hdparm -I /dev/${WKG_DRV} 2>/dev/null | grep -o 'TRIM')"
  #run 'fstrim' after $WKG_DEV mounted, every 20th bootup...
 fi
fi

...yes, unfortunate. The initrd has the busybox 'hdparm'. The full version, from 'util-linux' package I think, does handle ATA and USB drives. A bit further down in the 'init' script...

###TRIM###
if [ "$TRIMflg" ];then #200302
 [ ! -f /mnt/${BOOT_DEV}/${BOOT_DIR}.easyos-bootcnt ] && echo -n '0' > /mnt/${BOOT_DEV}/${BOOT_DIR}.easyos-bootcnt
 BOOTCNT=$(cat /mnt/${BOOT_DEV}/${BOOT_DIR}.easyos-bootcnt)
 BOOTCNT=$(($BOOTCNT+1))
 if [ $BOOTCNT -gt 20 ];then
  BOOTCNT=0
  echo -n -e "\\033[1;35mExecuting fstrim on SSD working-partition...\\033[0;39m\n " #purple
  fstrim -v /mnt/${WKG_DEV}
 fi
 echo -n "$BOOTCNT" > /mnt/${BOOT_DEV}/${BOOT_DIR}.easyos-bootcnt
fi

...so 'fstrim' will run every 20th bootup. I did read a recommendation to do it once a week, but it is a very non-critical thing. Though, there is a warning that some SSDs can actually be harmed by doing it too often. Hmmm.

Regarding USB-sticks, only one of mine supports TRIM, my 64GB USB3 SanDisk Extreme -- this has an actual SSD controller chip in it, and is very fast -- not sold in the local shops, I bought it off eBay, over a year ago. Busybox 'hdparm' won't recognise it anyway.

It is going to be interesting to see what delay this introduces at bootup. Most people run fstrim as a cron job, and I think that systemd does the same, so it runs in the background after bootup -- but I would prefer to get it out of the way at bootup -- also, apparently usage of the computer while fstrim is running can cause trouble, even drive corruption.  

Tags: easy