WebIF Feature Request: Show Filesystem State

[bottletop]

There is a 'Filesystem state:' in the (Linux) filesystem superblock. It can be checked via tune2fs or dumpe2fs.
If it is accurate, then it'll be useful to include that on the WebIF - eg on diagnostics page.
It'll allow users determine if further tests like fix-disk are due on their HDR (eg after a crash).

 

[/df]

I'm not sure that we know enough about what this value means in our relatively ancient ext implementation to expose it to users, but, as you suggest, there could be an ext FS diagnostic.

 

[prpr]

I'm not sure how you'd test it either. How do you deliberately corrupt an ext3 filesystem?

 

[bottletop]

I'm not sure how to test it either. I thought I'll suggest this after a recent issue. I ran dumpe2fs -h on the partitions, noticed it reported errors on the main one and promptly used maintenance mode fix-fisk.
fix-fisk performed it's magic and now dumpe2fs -h no longer reports errors.
Unfortunately I can't reproduce the scenario, but it occurs to me that the HDR occasionally hangs or requires a power off using the rear switch (which may sometimes lead to filesystem issue). I just thought a Filesystem State indicator may be useful. Eg prompt user to run fix-fisk before it affects recordings or the HDR

Maybe others can try checking their HDR (assuming it's safe to do so) by

 dumpe2fs -h /dev/sda1 |grep state ;dumpe2fs -h /dev/sda2 |grep state ;dumpe2fs -h /dev/sda3 |grep state.

Or (if they have virtual-disk2 installed)

 dumpe2fs -h /dev/sdb1 |grep state ;dumpe2fs -h /dev/sdb2 |grep state ;dumpe2fs -h /dev/sdb3 |grep state.

So, on my HDR, it now shows

Spoiler: dumpe2fs

#  dumpe2fs -h /dev/sdb1 |grep state ;dumpe2fs -h /dev/sdb2 |grep state ;dumpe2fs -h /dev/sdb3 |grep state
dumpe2fs 1.42.13 (17-May-2015)
Filesystem state:         clean
dumpe2fs 1.42.13 (17-May-2015)
Filesystem state:         clean
dumpe2fs 1.42.13 (17-May-2015)
Filesystem state:         clean

I thought something like this additional info on one of the web pages

/mnt/hdr1	/mnt/hdr2	/mnt/hdr3
clean	clean	clean

Where 'clean' should be the actual returned state.

Edit1: Additional info
https://serverfault.com/questions/8...s-erroneous-with-etc-fstab-errors-continue-se
http://www.tldp.org/HOWTO/Filesystems-HOWTO-6.htm
I haven't found a list, but a quick web search suggests the filesystem state may be clean, clean with errors, not clean (there may be more).

I'm not sure how you'd test it either. How do you deliberately corrupt an ext3 filesystem?

Maybe carefully usedebugfs? According to this https://ngelinux.com/how-to-force-f...rticular-drive-during-system-reboot-in-linux/