rheumatoid-programme6086

I am running 6.12.10, it is from before the regression you mentioned. Diagnostics are attached, untouched except for redacting some share names and user names. tiny-diagnostics-20240831-2345.zip

I have a server with 7 disks in the main array -- 2 parity, 5 data. Until yesterday, I'd only had 4 data disks, and I never though anything of the fact that they never spun down, because I have various apps that probably hit them periodically (plex, jellyfin, nextcloud, qbittorrent), so I never thought anything of it. Yesterday I added a freshly pre-cleared disk to the array, and it has literally nothing on it and wont for a while (I use fill-up allocation). Despite this, it doesn't spin down either. I have write method set to read/modify/write, spindown delay set to 15 minutes. What else should I change to get this disk to spin down?

root@tiny:~# zfs list -t all NAME USED AVAIL REFER MOUNTPOINT cache 48.9G 1.71T 120K /mnt/cache cache/appdata 13.9G 1.71T 13.9G /mnt/cache/appdata cache/cacheTemp 24.4G 1.71T 24.4G /mnt/cache/cacheTemp cache/domains 96K 1.71T 96K /mnt/cache/domains cache/system 10.6G 1.71T 10.6G /mnt/cache/system

Could you please point me to directions on how to do the ZFS replication? Thanks!

You are correct that the new drives are SSDs .... I was using the term 'disk' generically. The only thing in my cache is appdata. When I first added the cache, I stopped docker, copied all of the appdata from the array to the cache, pointed all of the docker containers at the new location, and started docker back up. A bunch of the containers malfunctioned or lost their settings anyway. Will ZFS pool replication avoid this problem? If so, I could use help with how to do it. If not, is there a way I can get Unraid to just create the partitions at the location they're in on the current SSDs

Also, here is the fdisk result for the disk that is "too small": root@tiny:~# fdisk -l /dev/sdg Disk /dev/sdg: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: CT2000MX500SSD1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Pool was created on Unraid. root@tiny:~# fdisk -l /dev/sdb Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: SSD-PUTA 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: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdb1 64 3907029167 3907029104 1.8T 83 Linux root@tiny:~#

Hello, I am attempting to replace my ZFS pool disks. Presently they are two 2TB USB SSDs, which are slow because they cannot be TRIM'd due to Unraid's lack of UAS support. I am replacing them with 2TB sata disks. Per lsblk -b, the devices are exactly the same size. In the output below, the disks that I am attempting to replace (1 at a time) are sdb and sdc, and I am attempting to replace them with sdd and sdg. Unfortunately, I get an error stating "replacement device is too small" when attempting to start the array after selecting one of the replacement disks into the pool (using the GUI). Thanks for your help! root@tiny:~# lsblk -b NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 62644224 1 loop /lib loop1 7:1 0 345944064 1 loop /usr loop2 7:2 0 21474836480 0 loop /var/lib/docker/btrfs /var/lib/docker sda 8:0 1 8032092160 0 disk └─sda1 8:1 1 8031043584 0 part /boot sdb 8:16 0 2000398934016 0 disk └─sdb1 8:17 0 2000398901248 0 part sdc 8:32 0 2000398934016 0 disk └─sdc1 8:33 0 2000398901248 0 part sdd 8:48 0 2000398934016 0 disk sde 8:64 0 14000519643136 0 disk └─sde1 8:65 0 14000519593472 0 part sdf 8:80 0 14000519643136 0 disk └─sdf1 8:81 0 14000519593472 0 part sdg 8:96 0 2000398934016 0 disk sdh 8:112 0 14000519643136 0 disk └─sdh1 8:113 0 14000519593472 0 part sdi 8:128 0 14000519643136 0 disk └─sdi1 8:129 0 14000519593472 0 part sdj 8:144 0 14000519643136 0 disk └─sdj1 8:145 0 14000519593472 0 part md1p1 9:1 0 14000519589888 0 md /mnt/disk1 md2p1 9:2 0 14000519589888 0 md /mnt/disk2 md3p1 9:3 0 14000519589888 0 md /mnt/disk3

I am still facing this frustrating problem months later. The only solution I have is to remove the drives from the unraid box and TRIM them on another machine, which is a huge pain and just a ludicrously bad solution. Does anyone know if it's possible to build a custom kernel with UASP support? Considering that UASP is needed to TRIM both SSDs and SMR drives, and significantly enhances the performance of UASP-capable DAS enclosures, I'm really surprised that this relatively simple change (enabling UASP in the kernel build) has not been made.

To clarify what I meant by "negating all of their [usb SSDs] benefits" -- The USB SSDs I have see a 5-10X reduction in performance after they become fully 'dirty' as compared to an Ubuntu system that supports UASP and has been configured to properly TRIM them. While UASP support might not have been a big deal performance-wise for HDDs six years ago when this feature request was originally written, it's a huge deal for SSDs in the present era.

Hi ... I'd love to see a feature added that can enable Turbo Write automatically once a configurable threshold is passed for write rates (if overall write rate stays above X MB/sec for Y seconds), and automatically turns off when the write rate falls under a similar configurable threshold. I love turbo-write mode's performance for things like adding files to my plex server, but at the same time, I don't necessarily want to spin up all of my disks every time 2kb is written to a log file somewhere. This way, if a large amount of data is coming into the server, it'd automatically "accelerate" after the first few seconds of slow writing.

Unraid doesn't support ARM. It's a no-go on an Orange Pi.

Bump...

Wondering if there has been any progress on UASP support? With USB speeds now surpassing SATA and the availability of several high-quality USB SSDs (and USB NVMe adapters), USB has become an interesting option for cache on NVMe and PCIe slot constrained systems ... but without UASP, USB SSDs cannot be TRIMed, negating all of their benefits.

Hi, I'm using a USB SSD as a cache and I'd like to get TRIM working on it (otherwise the performance falls off dramatically after a while). Unfortunately, it seems that in order for this to work, the drive must be connected via UASP. I'm hoping someone here has been down that path already and can let me know whether it's even possible to get UASP working on Unraid. Thanks!