March 8, 20197 yr Good afternoon, I did some searching around the forum, but couldnt find anything that fit my situation and was looking for some insight. I have a RAID10 cache pool with 4x 250GB SSDs. The setup is really new so there's not much on it yet. THe following shares are set to "Prefer": appdata, domain, and system. Docker and VMs are enabled, with both the Docker and VirtIO img files being shown as residing on the Cache. When the Unraid server has just booting up and the Array has been started the Cache shows that 25.0GBs are in use (see the image named cache-refresh-reboot) im, which is normal. It contains the Docker img (20GB), libvirt img(1.07GB) and Krusader docker data. However, after the system has been on for some time and I do file copies in Krusader, the cache seems to report only 7GBs of space being used (see image named cache-after-krusader-launch) Only thing I've seen that is short of related is that if you use different sized SSDs , then the amount is under reported (see this link Changing Cache Raid Mode ). But all mine are the same size SSDs. Any insight? Has anyone else seen this behavior before?
March 9, 20197 yr Community Expert 1 hour ago, chigaimaro said: Has anyone else seen this behavior before? I believe I remember something similar before, maybe because docker.img is a sparse file, nothing to worry about but if want post diags from both situations to compare.
March 10, 20197 yr Author On 3/8/2019 at 7:02 PM, johnnie.black said: I believe I remember something similar before, maybe because docker.img is a sparse file, nothing to worry about but if want post diags from both situations to compare. I finally got to test the system and these are the diagnostics , outside of the BTRFS raid reporting different usage sizes, everything else looks normal clean-boot-diagnostics-20190308-1925.zip after-size-reduction-diagnostics-20190309-1901.zip
March 10, 20197 yr Community Expert I'm guessing the reduced used space is because of trim, it's likely "re-sparsifying" the docker image, you can check next time if it happens after trim runs, either way safe to ignore P.S. there a connection problem with cache2, likely needs a new/better cable, Samsung SSDs ave very picky with cable quality. Mar 9 03:01:34 ninja-lager kernel: ata9.00: configured for UDMA/133 Mar 9 03:01:34 ninja-lager kernel: ata9: EH complete Mar 9 03:02:05 ninja-lager kernel: ata9.00: NCQ disabled due to excessive errors Mar 9 03:02:05 ninja-lager kernel: ata9.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen Mar 9 03:02:05 ninja-lager kernel: ata9.00: failed command: SEND FPDMA QUEUED Mar 9 03:02:05 ninja-lager kernel: ata9.00: cmd 64/01:08:00:00:00/00:00:00:00:00/a0 tag 1 ncq dma 512 out Mar 9 03:02:05 ninja-lager kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Mar 9 03:02:05 ninja-lager kernel: ata9.00: status: { DRDY } Mar 9 03:02:05 ninja-lager kernel: ata9: hard resetting link Mar 9 03:02:05 ninja-lager kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Mar 9 03:02:05 ninja-lager kernel: ata9.00: supports DRM functions and may not be fully accessible ### [PREVIOUS LINE REPEATED 1 TIMES] ### Mar 9 03:02:05 ninja-lager kernel: ata9.00: configured for UDMA/133 Mar 9 03:02:05 ninja-lager kernel: ata9: EH complete Mar 9 03:02:05 ninja-lager kernel: ata9.00: Enabling discard_zeroes_data
Archived
This topic is now archived and is closed to further replies.