New answers tagged fsck
Probably the best way to handle this is to reboot the system into single user mode, and do the fsck by hand. If, for whatever reason, that's not an option for you, the next best way to handle it is to twiddle a couple of rc.conf knobs. Specifically, these: background_fsck="NO" fsck_y_enable="YES" fsck_y_flags="-f" Reboot, and the rc subsystem should take ...
tune2fs is a tool from e2fsprogs for handling ext2/3/4 file systems :) For FreeBSD UFS, tunefs can be used, but it's not able to set anything fsck related. There's a lengthly discussion about forcing fsck after a reboot, the best answer from this thread seems to be "don't" and rely on background_fsck="YES" or force it via /etc/rc.early: echo '/sbin/fsck -y ...
Given EXT4 is journaled, it's unlikely that you lost any data in the process. Having orphaned inodes after an abnormal shutdown is normal (see Serverfault) so those inodes are probably related to temporary files that won't give you much back if you were able to recover them. In short, you probably could, but it's unlikely you'd want them.
Top 50 recent answers are included