Jump to content

KYThrill

Members
  • Content Count

    302
  • Joined

  • Last visited

Community Reputation

0 Neutral

About KYThrill

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  1. Well, my unRAID apparently decided to make a liar out of me. After clearing the statistics yesterday, and having it sit for over 24 hours with no writes (at least that I initiated), all the drives still read 0 writes, except for one 4TB, which shows 36 MB of writes. It also shows 22 MB of reads, which is odd, because there is no file on that drive smaller than 1 GB. So it wasn't a file transfer. I'm preclearing a disk, but as soon as that is done, I'm going to do a parity check just to see if it says anything.
  2. I should add that I have added some plugins that I didn't use before. Could any of them be consuming drive space, without adding a file to the directories. Community Applications Dynamix Cache Directories Dynamix SSD Trim Fix Common Problems Statistics Docker is disabled. I just reset statistics, so I will see what happens in the next hour.
  3. Does anyone have any idea if unRAID 6.4 could suffer from parasitic drive writing bug? For example, I have some drives in my array that I rarely ever write to. The remaining capacity on one had been 204 GB for over a year. Then I switched to unRAID 6.4 a week ago. Now I consistently see these small writes to the drive, 4 MB here, 4 MB there The free capacity on the drive is down to 196 GB now (so 8 GB of data written to it in a week, since switching to 6.4). However, there are no new folders, and no new files on the drive. This seems to be occurring on every drive, and not just one. I cleared the stats on my drives, and over night, every drive showed at east 80MB of writes, with some showing more. I rebooting about an hour ago. Every drive created at 4 MB of writes immediately upon the reboot, with some as high as 18 MB. Since then, the drives showing 4 MB of writes are now showing 16 MB of writes (the highest showing 41 MB), yet I have made sure that not a single thing was written to unRAID during that one hour period. What could this be? Is unRAID somehow using some sort of disk caching now to run the OS? All my drives just seem to be loosing storage space while just sitting, with no new files being added? In my 8 years with unRAID, I have never noticed this behavior, but it seems to be constantly occurring after a switch to 6.4. Any ideas? What could cause this behavior?
  4. Didn't even think to look at parity check history. Averages around 13.5 hours at around 82 MB/s on average. Don't have any numbers from 5.X. Was probably faster back then, because I switched to 6.1.6 to add 4TB drives. So all 5.X checks would have been against all 2TB drives, and recent numbers from history are a mix of 2 and 4 TB drives. That 80+ MB/s range is what I was seeing in 5.X too.
  5. I'm also looking at getting an Athlon X4 615e, which is 4-core and still 45W like the Sempron. That should be more than enough to run MariaDB and a headless Kodi, if I go that route.
  6. I really didn't time any parity checks and it has been a couple of years since I switched from 5 to 6.1.6. I usually start my parity checks at night before I go to bed, and when I get home from work the next day, it's finished. So fast enough for me. I want to think the time estimate is normally around 14-16 hours, but I don't remember exactly. It's 19, 2 and 4 TB drives. Almost ready to put in my first 8TB parity and 8TB data disk, so I expect parity check times to be increasing soon.
  7. Well, for better or worse, I changed two things... I have not seen a CRC error on Teracopy yet, so fingers crossed (but it hasn't been a week yet, and I was seeing 1-2 errors per week). Reviewing Linux kernel bug logs, I found many past issues with Samsung SSD's. Apparently they are not a good choice for a Linux device. However, there were many fixes for Samsung SSD's, spread over various kernel versions. One thing not working correctly was TRIM. So the first thing I did was update to unRAID 6.4 (from 6.1.6), just to get the newest version of the kernel as possible. I also installed the Dynamix TRIM plugin and set a daily schedule for that. The second thing I did, at the same time (I know, once change at a time is best) is change the SSD formatting to XFS. I had found numerous reports of data corruption using BTRFS or EXT4 on Samsung 850 SSD's. They don't seem to play well together, likely because of Samsung's Linux bugs in firmware. Often, when a user was getting data corruption with either of these, they would switch to EXT3, and everything would be fine. My theory on this is that EXT3 doesn't support TRIM, but EXT4 has TRIM support. Samsung acknowledged a buggy TRIM support for Linux (but works in Windows), which lead to kernel fixes to work around Samsung's implementation. So TRIM doesn't play well on Samsung SSD's, depending on file system. XFS looks like it supports TRIM (fstrim/discard), but I read some more info that indicates that may be misleading. The reason is that with XFS, TRIM is disabled by default. The preferred method for TRIM with XFS is to call it, which you can schedule with cron (which is what I think the Dynamix plugin is doing). So everything appears to be working, but I would not advise anyone to put a Samsung SSD (or M.2) into an unRAID machine. It seems like using this combo together could be risky. But since I already have one, since this is just the cache drive, and since XFS/Dynamix plugin seems to workaround the problem, I don't have much at risk.
  8. Yes, I've been running it since 5.0.2, but no problems with unRAID 6.1.X. I just updated to 6.4, but didn't see a workload increase because of that (CPU still around 4% and RAM around 20% utilized). However, I did enable Docker (first time) and added MariaDB. Memory is up to 56% and 22% CPU while idling. I doubt I have much capacity to do anything else and keep some overhead. I will need to see what happens to system resources if I have to serve up files to 3-4 clients. Docker/MariaDB may have to go, or system be updated. Fortunately, I think my MB will accept up to an 8-core Phenom, and is only using 1 stick of RAM, so tons of room to expand on that front, at the cost of power consumption. In the past, serving up files to 3-4 clients with a 54TB server has averaged less than 100 Wh power consumption. At idle it is around 20 wH. I'll miss the power consumption as I update.
  9. 1 pass of memtest and 0 errors. I know, just one pass, but...
  10. Does either docker add much overhead to the hardware? Curernt only use 24% of 2GB and CPU is hardly ever over 4%. May go up around 20% when a couple of people watch something. But it is just a single core CPU... so don't know how much I can expect unRAID to do.
  11. The only advantage that I see to the shared DB is the ability to pause on one machine and resume the same spot on another. Or is that only something Emby can do? To throw another wrench into things, my current Dune/unRAID configuration is offline. It is on a standalone sub-net in my house. I keep it isolated from all other PC's and outside influences to prevent ransom ware, file theft, etc. I have a dual NIC PC. About once per week, I connect a physical cable to my second NIC on my PC. I copy over new files and scrape DFI data, run goodsync to sync the DFI data to all my Dunes, and then pull the plug on the ethernet cable. That brief 30-60 minute period once per week is the only time there is any potential threat exposure to my unRAID. Trying to figure out a similar process to work with Kodi.
  12. Also, may be important: Jan 1 21:55:34 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 1 21:55:34 TOWER kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0 Jan 1 21:55:34 TOWER kernel: ata4.00: configured for UDMA/133 Jan 1 21:55:34 TOWER kernel: ata5.00: disabling queued TRIM support Jan 1 21:55:34 TOWER kernel: ata5.00: ATA-9: Samsung SSD 850 PRO 256GB, S39KNX0JA32484E, EXM04B6Q, max UDMA/133 Jan 1 21:55:34 TOWER kernel: ata5.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 31/32) Jan 1 21:55:34 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 1 21:55:34 TOWER kernel: ata5.00: disabling queued TRIM support Jan 1 21:55:34 TOWER kernel: ata5.00: configured for UDMA/133 ATA5 seems to be the SSD drive. After the first mover csum errror, this happened: Jan 4 21:26:42 TOWER kernel: ata5.00: exception Emask 0x10 SAct 0x7ffeffff SErr 0x400000 action 0x6 frozen Jan 4 21:26:42 TOWER kernel: ata5.00: irq_stat 0x08000000, interface fatal error Jan 4 21:26:42 TOWER kernel: ata5: SError: { Handshk } Jan 4 21:26:42 TOWER kernel: ata5.00: failed command: WRITE FPDMA QUEUED Jan 4 21:26:42 TOWER kernel: ata5.00: cmd 61/40:00:88:f7:79/05:00:00:00:00/40 tag 0 ncq 688128 out Jan 4 21:26:42 TOWER kernel: res 40/00:90:48:b3:79/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jan 4 21:26:42 TOWER kernel: ata5.00: status: { DRDY } Jan 4 21:26:42 TOWER kernel: ata5.00: failed command: WRITE FPDMA QUEUED Jan 4 21:26:42 TOWER kernel: ata5.00: cmd 61/40:08:c8:fc:79/05:00:00:00:00/40 tag 1 ncq 688128 out Jan 4 21:26:42 TOWER kernel: res 40/00:90:48:b3:79/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jan 4 21:26:42 TOWER kernel: ata5.00: status: { DRDY } the failed command portion (yellow and three lines after) is repeated 30 times or so, and ends with: Jan 4 21:26:42 TOWER kernel: ata5: hard resetting link Jan 4 21:26:43 TOWER kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jan 4 21:26:43 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 4 21:26:43 TOWER kernel: ata5.00: disabling queued TRIM support Jan 4 21:26:43 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 4 21:26:43 TOWER kernel: ata5.00: disabling queued TRIM support Jan 4 21:26:43 TOWER kernel: ata5.00: configured for UDMA/133 Jan 4 21:26:43 TOWER kernel: ata5: EH complete And after checking the log, the mover csum error hasn't happened as much as I thought. It has happened 3 times in 16 days, and only one of those three times was a file that Teracopy also failed. The other two were files Teracopy moved with no errors. And all the Teracopy files that error, only one had a mover error. Weird.
  13. For 8 years, I used a regular Samsung HDD for a cache drive. I transfer all the files to my Dune using Teracopy, with checksum verification. I recently decided to replace the HDD with a Samsung 850 PRO SSD. It is btrfs (I don't remember if the HDD was, I think it may have been xfs). I've had it in for about two weeks now, and probably have had a dozen times where Teracopy gave me an error because checksum failed verification (copying from my PC to unRAID). I've had to try copying a file as many as 3 times, before eventually passing checksum. I've never had to do that before. Checking my logs, I am seeing several times a week where Mover is also giving checksum errors and repeatedly needing to copy a file. Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 I get errors like this (sdf1 is the cache drive) during the mover process, and it will try again. If eventually unable to move without csum error, it just errors out, leaves the file, and moves on to the next. I've never seen this kind of error in 8 years (admittedly, don't check every night, but never saw one). Lot's of people use SSD cache drives. What could be wrong? Should I witch to XFS, like the old HDD? When I check the SMART data, I only have 1 UDMA CRC error count. I think if I had bad cabling, this number would be higher (386 hours powered on). There are no other errors of any type indicated in the SMART data. My only other thought is that I have some bad RAM. I have had a stick go bad in the past, which caused a failed CRC check on every file transfer. Just seems odd that this started happening the first day after installing the SSD (SSD is physically far away from RAM, so shouldn't be any type of electrical noise issue). The other wrench in that though, is that about 10% of my transfers from PC to unRAID are not to cache drive, but directly to array HDD. In the same 2 weeks, none of those transfers have had a checksum failure. Obviously, mover doesn't move those, so no data point there. It seems like if it were RAM failing, at least one of those would end up with an error too. Any ideas?
  14. I've been using unRAID for a number of years to run a couple of servers. One of them is simply a media server that feeds MKV content to 5 Dune Media Players. The writing is on the wall that the life of this Dune network is limited. I've ordered a Pi3 and plan to install LibreElec to run Kodi. My unRAID is pretty vanilla. I don't run any Dockers. I don't run any VM's. Hardware is only a Sempron 145 with 2GB RAM to minimize power consumption. But I'm sure there are some folks out there serving up content to standalone Kodi boxes. What am I looking at to set this up? Is it a mySQL docker? MariaDB? Emby? I see lots of threads for troubleshooting people's setups, but couldn't find a primer for getting started with unRAID. Any help would be appreciated. Thanks!
  15. I am a bit confused about why you are turning off autoneg. As I was looking into this parameter, I seemed to get the sense that this is the automatic negotiation of the NIC connect speed. Am I totally confused or is there some other issue that I am not aware of? This is autonegotiation of flow control. There are many autonegotitations. If you are connected to a switch that has flow control you can't disable, then if you don't turn autoneg off, flow control will automatically turn back on the instant you turn it off (so it will look like rx off does nothing).