Hi, thanks to some really kind and patient people here I now have an entertainment system set up with Espressobin V5 running OpenWRT v 19.02.1 with Samba 4 installed. The problem I have discovered is that the system automatically reboots when I start a mass file-copy from Windows to the Samba4 OpenWRT server. I also saw this same problem running OpenWRT v 18.06.04 with the same setup and it was my hope that upgrading to 19.02.1 would help but it didn't. The system is as basic as can be and consists of a Samba 4 install "right out of the box" with a completely open system on my LAN configured only with 3 directories off of my USB3 6TB drive formatted ext4 and defined to my USB3 hard drive which is mounted ext4 as /mnt/sda2/.
The server will run all day until I throw some 2GB files at it copying from either windows as movies and I've also discovered it also reboots when copying a TWRP backup archive off an Android device and archiving on the server. So it seems relative to the server here being over taxed. All I have done so far is prove it can fail and it stops and reboots consistently after copying about 4GB of data or less. Watching a 4GB HD movie via Kodi from a Kodi Samba client does not take it down, however.
Is there any way I can set up a log file to see what is going on or is there a Linux command like Windows chkdsk /F that is non-destructive to the data on the disk but scans and repairs any defective areas? I think I should run a routine to check the disk and/or set up a log file.
I've put a monitor on the voltage and it doesn't fluctuate off 5VDC and I've also set up a current meter and the maximum load I have seen during the copy and before it reboots is 0.6A (600ma) with a power supply that has a capacity of 6A. Thanks in advance!
Do you also have some kind of heatsink/cooling as it may be simply overheating on its own?
If you can, hooking up serial would probably be the easiest way to tell whats going on.
First I was using the wrong power supply. The board is designed for 12VDC. How it has run for 5V for weeks is a mystery to me. Still supplying the proper voltage did not fix the problem. Going to try to check the disk integrity.
Otherwise I discovered how to test the disk. I assume everything is all right with this disk (3 cheers for plagiarism and stealing this command from another post)
root@OpenWrt:~# umount /mnt/sda2
umount: can't unmount /mnt/sda2: Resource busy
root@OpenWrt:~# /etc/init.d/samba4 stop
root@OpenWrt:~# umount /mnt/sda2
root@OpenWrt:~# fdisk -l
Disk /dev/mtdblock0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mmcblk0: 28.99 GiB, 31104958464 bytes, 60751872 sectors
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: dos
Disk identifier: 0x15828375
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 35327 33280 16.3M 83 Linux
/dev/mmcblk0p2 36864 561663 524800 256.3M 83 Linux
Disk /dev/sda: 4.56 TiB, 5000981078016 bytes, 9767541168 sectors
Disk model: 000-1FK178
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 93E2D20F-5E10-3CD5-D21F-BB4C9C113531
Device Start End Sectors Size Type
/dev/sda1 2048 2047999 2045952 999M Linux swap
/dev/sda2 2048000 9767536063 9765488064 4.6T Microsoft basic data
root@OpenWrt:~# e2fsck -y -v -f /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 596 extent tree (at level 1) could be narrower. Optimize? yes
((((((((***** thousands of extent trees optimized here ... DELETED for display
Inode 62259202 extent tree (at level 2) could be narrower. Optimize? yes
Inode 63176706 extent tree (at level 1) could be narrower. Optimize? yes
Inode 63176710 extent tree (at level 2) could be narrower. Optimize? yes
Inode 63307778 extent tree (at level 2) could be narrower. Optimize? yes
Inode 63307781 extent tree (at level 1) could be narrower. Optimize? yes
Inode 63438850 extent tree (at level 2) could be narrower. Optimize? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
99683 inodes used (0.03%, out of 305176576)
1241 non-contiguous files (1.2%)
91 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 98520/1132/23
259961681 blocks used (21.30%, out of 1220686008)
0 bad blocks
14 large files
90542 regular files
9132 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
99674 files
root@OpenWrt:~#
type or paste code here
*** correction: My recent report of this device not pinging was due to a typo likely caused by the fatigue and frustration factor of the operator
I'd still like to figure out how to completely back this thing up so while I am struggling with it, to restore it without having to reconfigure, including not having to download all the packages and configure them again.
Not sure what to expect out of this little box. Still with the upgrade to 19.02.1 I get only maximum speeds of 10.2M/s copying from a Windows machine to the server over direct attached LAN cable. The e2fsck scan and fix routine seems to have stopped the reboots but I still get errors copying very large files. And for example while downloading via Transmission at 500K, and if I try to watch a 700M video from an older file on the same drive, I can expect the video on Kodi to freeze a couple of times during an hour long program where rebooting the Firestick is normally required to unfreeze it during that process. This doesn't happen if the Kodi activity is the only thing happening on it at the time.
So overall while this was a great novelty project, I think I may just be asking too much of it to do things like multi task. The hard drive it is using incidentally has a very high transfer capacity when direct attached to Windows and is currently attached to the USB3 interface of the espressobin board.
Another irritating thing I have to bring up in trying to use this espressobin server is that the Luci option to restart the device has never worked. After I do a restart it stops responding but I actually have to go to the server and power cycle for it to come back up.
10Mbyte/s does sound low, my old WRT3200ACM (by now) does speeds 4x+ times your device over USB3 and yours isn't that slow. What does top look like when transferring files? Is the device connected directly do the Espressobin board? Is link speed 1000mbit (and not hardset)?
I can however tell you that transmission doesn't play nice with other software when it comes to disk access. During preallocation (if enabled) and final file copying it would cause Samba to crawl on my FreeBSD box which I never could fully mitigate. I've since then moved to qbittorrent (libtorrent-rasterbar) which performs much better in all ways however it depends on QT (even the noX variant) which is quite large and not ported to OpenWrt. You can give it (transmission) less priority I/O-priority however I have no idea how that affects performance.
Diizzy I can't thank you enough for all your help. I think I am going to "settle" and use this as-is unless someone else comes along with more ideas on how to improve performance. I've learned a lot and this may very well push me to the end of the OpenWRT platform and be "all I need to learn for a while". Considering I have been working with OpenWRT and continuing to learn for the past 7 years thanks to you and the other many who have commented here and thus held my hand through all this, I cannot thank you all enough. This is going to be "acceptable" at this point with always in the past having the desire to improve with with 7 years under my belt reaching this point I am with OpenWRT, I am not ready to switch versions and tackle one of the other Linux versions just yet.
As you know this has been a "hobby house" camper installation and everything is running off 12VDC or the 5VDC portions are fueled through 12VDC to 5VDC buck converters. I have the main Espressobin actually powered through a 6A boost/buck converter since the DC can reach as high as 14.8VDC with the solar panels so I have a 6A DC to DC boost/buck supplying the hard drive and the espressobin board. I discovered my Firestick with my setup was not getting the full 5V to the board and that was because there was some oscillation that existed due to the 5V cable being too long, causing the regulator (5V buck converter) to produce only about 4.3V and this was causing the locked displays and failure to respond. What I ended up doing was running a 12V wire directly to the firestick and installing the buck converter right next to the stick which gave me 5 pure volts and this stopped the Firestick locking up.
WIth the example fix-disk routine I ran (see previous post), this apparently fixed all my other problems except for the slow speed. I added the vsftpd package and with transmission running at a rate of about 500K (tested up to 2M data rate, as fast as my connection is capable), and at the same time using windows regular copy to copy a 800M file from the laptop to the server (10M/s top data rate) while also using Filezilla at the same time to copy a 4Gb file to the server via FTP (6Mb maximum data rate) and with me watching a 500M video via VLC on Windows and all at the same time, I accomplished all this while the server multi-tasked without a glitch. Do note that doing any of these file transfers alone without all the other tasks running doesn't seem to affect the data throughput rate that much. The 6M seems the max for FTP and around 11M seems the max for Samba4.
I haven't experienced a reboot since getting my voltages squared away and cleaning up the hard drive.
