Entware How to properly eject/dismount USB attached SSD with EXT2 file system?

[Limpi]

In your case, based on what you described above, it seems that what you might need to do, to avoid similar problems in the future, is to stop the Entware services from the "/jffs/scripts/unmount" script as well.

For example:

#!/bin/sh
# FILE: unmount #
...
...
RC_UNSLUNG="${1}/entware/etc/init.d/rc.unslung"
[ -x "$RC_UNSLUNG" ] && $RC_UNSLUNG stop
...

Thanks!

Currently, I do not have an unmount script at all! :-o

I just have a post-mount, with this content:
#!/bin/sh
. /jffs/addons/diversion/mount-entware.div /tmp/mnt/ASUS-480GB # Added by amtm

And a services-stop, with this content:
#!/bin/sh
/opt/etc/init.d/rc.unslung stop # Added by amtm

Should I create an unmount script too, with the same content as services-stop above?

(What I don't fully understand why the web admin UI's Eject (what does an unmount too) was working with EXT4+journaling file system and is not working now with EXT2 file system.
Everything else (entware, qBittorrent) was/is the same and all scripts were created by amtm.
So with EXT2 Asuswrt-Merlin+entware is not working as supposed, despite that it was working well with EXT4+journaling. EXT2 is less supported?)

 

[Limpi]

I put this together the other day. Give it a shot. I call it lsofalt.

[bash]
#!/bin/sh

cd /proc
this=`basename $0`
ran=y
for i in `ls -d [0-9]* 2>/dev/null | sort -g`; do
   opfi=`ls -lF ${i}/fd/ 2>/dev/null | sed -n '/\//{ /\/dev\//d
                                                    /\/proc\//d
                                                    /(deleted)/d
                                                    /'$this'/d
                                                    s/.*->/  /p }'`
   case $1 in
      +l* ) # to include .lock files as well
    ;;
      * ) [ "$ran" = "y" ] && { ran=n
            echo "#   pass \"+l[ocks]\" to not exclude any /var/lock/ files"; }
        opfi=`echo "$opfi" | sed '/\/var\/lock\//d'`
    ;;
   esac
   [ "$opfi" ] && { /bin/echo -en "\n$i\t"
      cat ${i}/cmdline | tr '\0' ' '
      echo
      echo "$opfi"
   }
done
[/bash]

Huh, that is a bit too complicated for me, but thanks anyway!

Creating an unmount script seems for me to be an easier and less hackier solution.
I just don't know why it was not created by amtm automatically...

But I will try your script if the unmount script does not do the trick for me.
(It is possible that rc.unslung stop is buggy for me and in that case it will not help to call it...)

 

[Limpi]

In your case, based on what you described above, it seems that what you might need to do, to avoid similar problems in the future, is to stop the Entware services from the "/jffs/scripts/unmount" script as well.

For example:

#!/bin/sh
# FILE: unmount #
...
...
RC_UNSLUNG="${1}/entware/etc/init.d/rc.unslung"
[ -x "$RC_UNSLUNG" ] && $RC_UNSLUNG stop
...

Is the {1} parameter the drive label in your script?
If yes, that would be great, because I only have entware on one of my two SSDs, so I only need to stop it when I unmount that one.

 

[glens]

All my script does is show you which processes have files (that you might be concerned about) open. It's a less-cluttered "lsof" Run it once and you'll see what I mean.

I don't have the same-enough setup as you so can't readily scrounge up a "umount" script.

Glad to see (it was expected) that you hadn't really needed to fsck in the first place.

I'd go with ext4.

 

[Limpi]

All my script does is show you which processes have files (that you might be concerned about) open. It's a less-cluttered "lsof" Run it once and you'll see what I mean.

I don't have the same-enough setup as you so can't readily scrounge up a "umount" script.

Glad to see (it was expected) that you hadn't really needed to fsck in the first place.

I'd go with ext4.

Oh, I see, thanks, I will try it!

I tried first EXT4 with journaling enabled (because amtm recommended it) but I had a lot of strange transfer errors with it and even 100% CPU utilization for a couple of seconds (and extreme slowdowns during it).
I first thought is is an USB cable error, then I suspected insufficient power (because I have two SSDs connected to the router's two USB 3.0 ports). But then I switched to EXT2 because of this: link
And it really solved all my problems, all transfer errors and slowdowns are now gone!
So EXT4 with journaling is really bad with entware+qBittorrent for me (don't really know why), but EXT2 works nice! (Except the fail of Eject/Unmount of the drive which now I will fix.)

 

[glens]

That article is more than a decade old. At a minimum, you should consider ext3 which is all but ext4 with the journal turned off.

 

[Limpi]

That article is more than a decade old. At a minimum, you should consider ext3 which is all but ext4 with the journal turned off.

Oh, I see, okay, I will try EXT3!

But what is wrong with EXT2? Why is EXT3 better? I just need qBittorrent to be stable.
That SSD will really do nothing else...

(I forgot to mention that I have an UPS (FSP Nano 800) before the RT-AX86U, so a shorter power outage will not interrupt it's operation. This way theoretically I will have only pre-planned power offs and restarts.)

 

[Limpi]

In your case, based on what you described above, it seems that what you might need to do, to avoid similar problems in the future, is to stop the Entware services from the "/jffs/scripts/unmount" script as well.

For example:

#!/bin/sh
# FILE: unmount #
...
...
RC_UNSLUNG="${1}/entware/etc/init.d/rc.unslung"
[ -x "$RC_UNSLUNG" ] && $RC_UNSLUNG stop
...

I created your unmount script and now Eject works well on the web admin's UI!
Thank you very much!!!

 

[ColinTaylor]

There's really no reason for not using ext4 with journaling enabled. The information in that link you provided was questionable at best. It might have some merit as an edge case where the entire filesystem was used for caching and you didn't mind having to reformat it every time it got corrupted. That's not a normal scenario. In your case you also have Entware and all of the associated software (e.g. qBittorrent) installed in the same filesystem. Do you really want to have to repair and reinstall all of that each time the filesystem gets corrupted just because you didn't have journaling enabled?

EDIT: Fixed typos.

 

[Limpi]

There's really no excuse for not using ext4 with journaling enabled. The information in that link you provided was questionable at best. It might have some merit as end edge case where the entire filesystem was used for caching and you didn't mind having to reformat it every time it got corrupted. That's not a normal scenario. In your case you also have Entware and all of the associated software (e.g. qBittorrent) installed in the same filesystem. Do you really want to have to repair and reinstall all of that each time the filesystem gets corrupted because you did have journaling enabled?

I don't know, I never got a corrupted file system so far...
But I got a lot transfer errors with EXT4 + journaling and less with EXT2.
There is no important data on the drive, just the torrent cache. I can download that again any time.
So I am not really scared. Should I be?
EXT2 will be corrupted at some point for sure? Despite the UPS and that the storage is an SSD?