0

I have a 80G hard disk attached to my PI2B and I have a couple of software running on it. I noticed that sometimes the disk becomes inaccessible and I would need to unmount and remount the partitions in the disk to recover access the files in the drive. This happens many times a day. So I was wondering if Raspberry PI switches off power supply to an USB port of it is not being used for some time, like some sleep activity? (This being inaccessible doesn't happen if there is some activity - read or write - on going in the drive). If there is, then how do I prevent it?

I thought of putting this as a comment to This Post but it didn't allow me to.

1

The maybes;

  • It maybe that you don't have the drivers installed on your RPi for the partition style that your hard drive uses. I had this issue with a Windows formatted hard drive but once I installed the ntfs drivers and beguan using UUIDs instead of relotive paths everything cleared up.

  • It maybe that your hard drive is not supplying enough power but that should only be the case if your hard drive is not externally powered. The advice you found at the link in your OP is only applicable if the drive is USB powered only & your RPi's ower supply is capible of enough current to handle both powering itself and prifferals. If you follow thos direction without proper power then you risk bad read/writes to the attached hard drives as well as damaging your RPi's OS because cutting power during writes to it's system files (like running apt-get upgrade) can corupt vital data.


The solutions I use on my RPi;

  • I searched for the missing drivers by using apt-cache search ntfs (ntfs because that was the format giving me the most issues) and then installed the missing drivers with apt-get install <packages>. By using the bellow blkid command with a little greping magic you can list a hard drive's partition format before attempting to mount. Hint awk '{print $3}' just after the grep -E 'UUID' will just print the verias partition formats that are plugged in.

  • The command I use to put the UUID into the /etc/fstab file shoud be tested and when it is outputting the info for your hard drive add | sudo tee -a /etc/fstab to the end of the bellow command to have it place the output (commented) into your fstab file. Then sudo nano /etc/fstab and remove the leading # to uncomment and reload with sudo mount -a to have changes take effect. I use this command and then nano because placing uncommented lines into fstab is just asking for some roge task (or car/branch knocking into power lines) to reboot my RPi before I have a chance to ensure that is error free.

: ${USER?} && blkid | grep -E "/dev/s" | grep -E "UUID" | awk '{print $3,$2,$4" uid=USER,gid=USER,umask=0022,sync,auto,nosuid,rw,nousr, 0 0"}' | sed -e 's/UUID=/#UUID=/' -e 's/LABEL=/\/media\//' -e 's/"//g' -e 's/=\([^" >][^ >]*\)/="\1"/' -e 's/TYPE=/ /' -e "s/USER/$USER/g"

  • Before scedualled reboots or power dows I'll also re-modify the fstab file to re-comment out external hard drives. This saves me lots of time when powering back up and reduces the chances of something within the RPi's boot processes from barfing from loss of power (due to reading the external drives) or from something on the drives causing errors.

By using the UUIDs I now no longer have issues with other drive formats becoming un-responcive either. However, if not used for a day or two the drives that are slow/old will take a second or two to become responcive to ls -hal /media/<drive_name> and other read commands. But once accessed once and spun up further commands to read and write run smoothly. Based off this I can say that there is more than likely some kind of power drop to the USB ports that hasn't been active for a while but when mounted such that it'll always mount to the correct directory it should wake back up when re-accessed.

  • Mine is not an ntfs partition. It's ext. Also my drive is externally powered! And my fstab is already configured to mount partitions using UUID. Still I face the issue. – Mathew Paret Aug 14 '15 at 8:22
  • That is darn odd... well untill someone with a bit more know-how pipes in here's a one liner that you can use to auto check. ls /media/<drive> | grep -E '<some_dir>' ; if [ $? != 0 ]; then umount /media/<drive> ; mount /media/<drive> ; fi just replace <drive> with the name that it's mapped to and <some_dir> to a real file/directoy name that is within the drive. On errors it'll unmount and remount the drive. After testing and adding checks for processes using the drive you can add this to a cron job and have generated logs by adding >> /var/log/drive_errors 2>&1 /dev/null to the end. – S0AndS0 Aug 14 '15 at 11:19
  • That's what I have been doing. Checking whether the partition is listing else unmount and mount. That's but a work around. I am looking for a permanent solution. Is there any logs that would help me understand why this is happening? – Mathew Paret Aug 15 '15 at 5:28
  • I had read that but thought that providing a scripted bandaid with logging enabled may make your life a bit easier on tracking if there is a paturn or rouge task killing the mount. By adding more commands between ]; and ; fi it's possible to log the times (ie date;) or other metrics of the RPi when remounts are required. Then by cating and greping through the other logs in /var/log/ that your RPi already generates it maybe posible that something is happening in the background that will be logged there. Have you tried the hard drive plugged into another device? Could be the drive. – S0AndS0 Aug 17 '15 at 22:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.