Domoticz

Maybe this is an idea for others, because this little hardware hack is around 20 bucks.

To prevent the wear out of your SD-Card, folders should be moved out from the card to a more robust memory. After a short view in the second hand i figured out that there are many tiny 1.8" ZIF harddisc's from audio players at the bay. As size have a look for 20gig but don't waste money for huge sizes. These tiny harddisc types require a cheap metal case with usb connector, you can get them most times below 10 bucks. Here is a video so you can see how to fit it.

https://youtu.be/P11Bbt2GX_8

Because you don't need and want to have the whole system on the harddisc as it's slower than the sd card, you like to place busy folders into separate partitions. Here as example how i did partition my 20gig drive in GPT mode.

Disk /dev/sda: 18,6 GiB, 20003880960 bytes, 39070080 sectors
Disk model: 0G5CE00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device Start End Sectors Size Type
/dev/sda1 2048 23420927 23418880 11,2G Linux filesystem
/dev/sda2 23420928 35067903 11646976 5,6G Linux filesystem
/dev/sda3 35067904 39069695 4001792 1,9G Linux swap

To add the disc to your raspbian, stop the domoticz service. Here sda1 is for the /home partition, so mount this for example at /mnt and copy all from /home on your sd card to the new partition. If you use "cp -pdRxv /home. /mnt/" it will prevent the permissions for all files. After that do the same with the /var partition that contains all logs, package archives and temporary files.

After copy the /etc/fstab have to be changed, to get the new partitions included into the sd card system at next boot.

Possible result.

domoticz@domosys:~$ more /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=6512e388-01 /boot vfat defaults 0 2
PARTUUID=6512e388-02 / ext4 defaults,noatime 0 1
/dev/sda1 /home ext4 defaults 0 1
/dev/sda2 /var ext4 defaults 0 1
/dev/sda3 swap swap defaults 0 0

After reboot the system will work with /home and /var on the harddisc and have a swap partition if memory will ever get a problem. The result can be probed with the df command.

domoticz@domosys:~$ df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 14780780 1769672 12378008 13% /
devtmpfs 443152 0 443152 0% /dev
tmpfs 447760 0 447760 0% /dev/shm
tmpfs 447760 22872 424888 6% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 447760 0 447760 0% /sys/fs/cgroup
/dev/mmcblk0p1 258096 40049 218047 16% /boot
/dev/sda1 11456638 1544948 9322122 15% /home
/dev/sda2 5697645 518633 4883742 10% /var

So the machine does have the fast sd-card boot and the robust harddisk partitions for busy places. Here i fitted the metal case with double sided stripes and a short usb cable on top to the Icy Box. For startup current on USB2 connectors the raspi need this line in /boot/config.txt to have enough power.

#USB-Current
max_usb_current=1
If there are questions left, just ask:-)
Solderbro

Hello,

I've done almost the same for my Domoticz Backup Raspberry platform (running 24/7). It works well for about one year now. Notice however that in my environment during this last year, two times, I lost the USB hard-disk. Even this USB hard-disk disconnection is for a few seconds, because Raspbian labels the hard-disk /dev/sdb instead of /dev/sda when the USB hard-disk comes back, I had to reboot the Raspberry to get everything working well again.

I don't know, maybe you will not have such problem in your environment because I understand you have installed all Domoticz stuff on the Hard-disk. In my environment, Domoticz core software is still on the SD-card, only the database and the SQLite Temp files are on the hard-disk. I've changed the /etc/init.d/domoticz.sh for that purpose.

It depends also if your Raspbian is headless or not. If not headless, there is an auto-mount feature (part of Desktop file manager) which takes care about such issue.

Antori91 wrote: ↑Saturday 24 August 2019 14:54 Hello,

I've done almost the same for my Domoticz Backup Raspberry platform (running 24/7). It works well for about one year now. Notice however that in my environment during this last year, two times, I lost the USB hard-disk. Even this USB hard-disk disconnection is for a few seconds, because Raspbian labels the hard-disk /dev/sdb instead of /dev/sda when the USB hard-disk comes back, I had to reboot the Raspberry to get everything working well again.

I don't know, maybe you will not have such problem in your environment because I understand you have installed all Domoticz stuff on the Hard-disk. In my environment, Domoticz core software is still on the SD-card, only the database and the SQLite Temp files are on the hard-disk. I've changed the /etc/init.d/domoticz.sh for that purpose.

It depends also if your Raspbian is headless or not. If not headless, there is an auto-mount feature (part of Desktop file manager) which takes care about such issue.

Use the blkid command to get the UUID of the hard drive partitions, stick those in /etc/fstab instead.
https://www.cyberciti.biz/faq/linux-fin ... ate-fstab/

asjmcguire wrote: ↑Saturday 24 August 2019 18:18 Use the blkid command to get the UUID of the hard drive partitions, stick those in /etc/fstab instead.
https://www.cyberciti.biz/faq/linux-fin ... ate-fstab/

Hello Asjmcguire,
I've already thought to use the solution you describe (UUID in fstab). But I didn't try it yet because I think (I may be wrong) it will not solve this issue. Why I think it will not solve the issue? Because when the USB hard-disk is back, the fstab content is not executed again, a new mount has to be issued. So I think you have to implement this new mount using udev rules for example...but yes using UUID. To summarize, I think there are two issues to solve:
1. to have a unique ID, this UUID is the way to use
2. a new mount has to be issued. Raspbian (in headless installation) doesn't do it.

PS: It seems there are two utilities which could maybe solve this issue: AutoFs and usbmount (Have to be installed - I didn't try them).

Had used usbmount on a headless Ubuntu years ago, as i remember it can mount by uuid to a specific mountpoint. But it's possible that Domoticz got a race condition with usbmount and will fail at cold start.

A stronger USB key was (or is) the Corsair Voyager that comes with a wear level controller, but i screwed one up in 6 months as proxy cache on a OpenWRT router. There are so called SLC usb key SSD on the market (Transcend / WinKOM), very expensive against the 2nd hand harddisk. I'm curious how long the tiny disk will survive 24/7 run.

Solderbro

Antori91 wrote: ↑Saturday 24 August 2019 19:21 Why I think it will not solve the issue? Because when the USB hard-disk is back, the fstab content is not executed again, a new mount has to be issued.

You're right and IMO, the usb disconnect you observe for your storage while mounted may be recovered (as you do not run your system on it) but this would be difficult as opened file handles on the terminated mount will be killed, so you'll have to restart all services using files on this external storage (domoticz etc)... Better reboot your PI if an unexpected /dev/sdb shows up IMO, so no risk to forget something.

So you should better figure out why you experience these usb disconnects (that should be logged in dmesg/syslog): From my experience in the embedded, this may be a combination of USB/Sata bridge and the way Linux usb-storage (a subset of SCSI layer) works. This is not a USB interface sometimes going to sleep because issue would show up much more frequently. I also suppose you do not have some undervoltage logs and your HDD have a good power supply.

Already had some (but not all!) USB flash storage controllers that time-out and disconnect when usb-storage subsystem is interrupted just between a command and data phase. In my experience probability was quite higher (several days, on telecom infrastructure hardware) because our Linux was including real-time patches: With theses patches, even applicative RT software can interrupt the kernel which is not possible using a stock kernel, increasing the probability to run in the issue. This was solved setting a RT priority for the usb-storage kernel thread just for the sensitive part (to avoid increasing too much latency for other RT stuff).

So, without debugging/patching the kernel yourself, another enclosure for your HDD with a different usb/sata bridge controller may work. Or just raise globally usb-storage kthread (as latency when storage kick-in should not be an issue for you) priority at startup.

Otherwise, even if usb_storage changed a bit, issue may be located there.
https://elixir.bootlin.com/linux/v4.19. ... usb.c#L298

To raise priority, if I insert a usb stick in a Linux PC I get this:

$ ps -ef | grep usb
root 678 1 0 juil.29 ? 00:01:14 /usr/bin/vmware-usbarbitrator
root 12059 2 0 11:28 ? 00:00:00 [usb-storage]

Or:
$ pidof usb-storage
12059

Current prio:

chrt -p 12059
pid 12059's current scheduling policy: SCHED_OTHER
priorité de planification actuelle pour le PID 12059 : 0

Valid ranges for each scheduler availlable on system:
$ chrt -m
SCHED_OTHER min/max priority : 0/0
SCHED_FIFO min/max priority : 1/99
SCHED_RR min/max priority : 1/99
SCHED_BATCH min/max priority : 0/0
SCHED_IDLE min/max priority : 0/0
SCHED_DEADLINE min/max priority : 0/0

To change scheduler/prio, for instance:

$ sudo chrt -r -p 99 12059

Check:

chrt -p 12059
pid 12059's current scheduling policy: SCHED_RR
priorité de planification actuelle pour le PID 12059 : 99

Good!

To put this all in one, from some startup script that may be executed as root and after usb-storage kthread is launched:

pid=$(pidof usb-storage);[ $? == 0 ] && chrt -r -p 99 $pid

with Pi3b+ it does NOT make sense to use SDCard anymore
boot straight from HDD!!!
https://www.raspberrypi.org/documentati ... des/msd.md

If I was going to do external storage for a Pi now I'd compile my own kernel, add ZFS and do RAID Z1 between a couple of small USB sticks.

I love BTRFS but ZFS is my all time favourite file system for data storage (and Ceph can be nice if there are 3 or more nodes).

emme wrote: ↑Wednesday 28 August 2019 11:40 with Pi3b+ it does NOT make sense to use SDCard anymore
boot straight from HDD!!!
https://www.raspberrypi.org/documentati ... des/msd.md

And if the issue shows up, usb disconnect uncleanly kills the whole system!

I have been running 2 pi's with wd pidrives for years on both 3A and 3B+ with no USB disconnects at all. Both systems boot from HD. Very stable.

Sent from phone.

heggink wrote: ↑Wednesday 28 August 2019 13:04 I have been running 2 pi's with wd pidrives for years on both 3A and 3B+ with no USB disconnects at all. Both systems boot from HD. Very stable.

As I explained hereupper, some usb/sata bridges or controllers have issues (whatever the HDD inside the enclosure).
Linux usb-storage implementation is nice for removable storage, but not really tested/designed for a boot (or even fixed) storage device: It's really a separate subset of the SCSI layer that just can't have it's reliability on par with internal storage stuff that experienced years of problems solving for any load/hardware in the server or PC world.

Even on the embedded market, with USB storage devices (so called eUSB) made with SLC flash chips and storage controllers firmwares tuned for an applicative+OS load (and not some sequential read/write bursts during some small uptime while plugged or when taking/loading some photos/videos), I experienced very tricky problems.

Now, most SoCs used in the embedded world have a reliable and dedicated storage interface (like Sata). So problem gone.

USB looks nice for the user, but is really a mess on the OS/driver side... and this starts with Intel specifications (that you'll find as cut&paste in almost any ARM/PPC... based SoC documentation as the IPs are mostly the same).