Leaderboard

Support thread for the pgadmin Docker template. Application Name: pgadmin Application Site: https://www.pgadmin.org/ Docker Hub: https://hub.docker.com/r/fenglc/pgadmin4/ Application Github: https://github.com/postgres/pgadmin4 Template Github: https://github.com/rroller/unraid-templates Admins: Please configure https://github.com/rroller/unraid-templates for use with CA. Thanks!

Shares will remain, but if you're using include/exclude disks you'll need to reset those. Once a disk fails it's much more likely to fail again in the near future, but it's hard to predict if that one will or not, it's up to you and the level of risk you're comfortable with.

Just to add my two bits: # mkdir test1 test2 # mount -o bind test1 test2 # dd if=/dev/urandom of=test1/file1 count=1k 1024+0 records in 1024+0 records out 524288 bytes (524 kB, 512 KiB) copied, 0.0744947 s, 7.0 MB/s # ls -l test1/ test2/ test1/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 test2/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 # cp -v test1/file1 test2 cp: 'test1/file1' and 'test2/file1' are the same file Seeing that cp can actually detect the same files on a bind mount, it stands to reason that SHFS is returning a different stat attributes than the underlying file, thus fooling cp that the source and destination are different files and safe to clobber in the usual manner. So it's a bug (or as some devs like to call it: limitation) with SHFS.

Considering it's pretty difficult to find anywhere with decent stock of 10TB drives, I'd guess probably not. I'm still buying 8TB drives (mostly HGST Deskstar NAS, which are nice helium drives similar to the Red Pro). Had no problems with any of them, including shucked WD Whites (80EZZX) which are well over 18 months old now.

We haven't seen any large number of early deaths from any of the drives - so no obvious hint of their production quality or longevity. You will know more about these disks sometime when it's time to decide on the best 25-30 TB disk on the market.

I think it's going to be difficult to get decent data on drives that haven't been around for a long time.

I found that too looking on stack, I ran the commands suggested to check the number of processes and threads being used and was at 15% of the maximum

Can you make it without the XEON logo in the middle? Looks awesome. Cheers. Here ya go mate... hope I didn't overstep a boundary with @perhansen by taking the initiative to do this.

Having one unRAID server act as a master and slave other servers user shares might be useful. So when one server is at capacity, you can slave a second/third etc with concatenation of user shares performed by the master.