• Content count

  • Joined

  • Last visited

  • Days Won


SSD last won the day on February 2

SSD had the most liked content!

Community Reputation

260 Very Good



  • Gender
  • Location
  • Personal Text
    ASRock E3C224-4L/A+, SM C2SEE/B, Asus P5B VM DO/C
  1. Security flaw discovered in Intel chips.

    Update on Spectre remediation from Intel. Concise description that helps better understand Spectre and the fixes.
  2. There were some changes to unRaid licensing with v6. Basically, it is counting all disks in the server against the license limit, and the limits have changed slightly. But the keys are the same and you don't need to do anything so long as your license is not exceeded. Note the key file needs to be in the config directory. The root is no longer searched for that file.
  3. I also bought mine on eBay. Low ball offer that was accepted. The CPU was professionally delidded by Silicon Lottery to replace the thermal compound between the cores and the IHS. Make it run much cooler. I ran a long rogue test with all cores running at 4.5Ghz and it is running vet stable.
  4. The NVMe.may be shared with the sata controller. Maybe there is a bios setting. What is your motherboard. Mine is the AsRock.x299 OC Formula. I liked it had extra PCIe slots.
  5. Disk Behavior - Trust or No Trust?

    "Any doubt" is a very high standard. For me it's all about is the problem getting worse. If the smart attributes are stable across several parity checks, I can live with a few issues I the smart attributes. But will say that I see fewer and fewer such issues with drives in past several years. As far as what to do with a disk that is giving problems. Often such drives work fine as backup drives, where their powered on time goes down drastically, and it's far better than nothing. Best to get such drives out of the array quickly to leave useful life for this purpose, rather than wait for things to get worse and worse, until the drive is worthless and sledgehammer is warranted.
  6. Disk Behavior - Trust or No Trust?

    When a sector is marked pending, the next write to that sector will check that sector and could decide it is ok (pending goes away) or decide to remap it (pending goes away but reallocated increments. SMART is designed to think of all errors as media errors, but media errors is only one possibility. With some of the symptoms you are mentioning, seems drive has other issues. I have seen disks where I have a small number of pending sectors that neither get worse or remap. Not sure if it is a bug in the drive's firmware or what. But I have not replaced such drives. I've also seen a few drives that mark a bunch of sectors pending initially, and then they all clear and drive seems none the worse for wear. You might try running an extended smart test. If it passes and smart attributes are stable, you might consider keeping it. But with symptoms you've reported, looks like it would need to be returned.
  7. Who needs an array? 30TB SSD...

    A big wallet! $10K at least!
  8. V5 is the beginning of support for drives over 2T. You'd have to reach out to Limetech to get the final v5 .zip file. Not sure there is a published minimum memory for v6 for NAS only use, just a recommended minimum. 1G may work if install is thin with no Dockers. I'd try that first, and only back down to v5 if required.
  9. Shares, discs and just general confusion!

    Ok, what is a mount point. Let's start with drive letters. When you add a drive to Windows, it gets a drive letter. The first disk is c:, then d:, etc. Linux doesn't work like that. Each new drive will get a device name, like /dev/sde, and that can be used to partition and format the disk. But in order to use the drive to add new files or access existing, it has to be mounted. Since Linux has no drive letters, instead a disk needs to be mounted before you can access its files. You might think since the disk is /dev/sde, you could create a file called /dev/sde/my file.txt. No, doesn't work like that. The disk is a closed book until it is mounted. To mount a disk, you create a folder, and then mount the disk there. So, for example, you could create a folder called /edrive. And mount /dev/sde there. Now by going to /edrive you can add new files to the disk and access existing files. The folder /edrive is its mount point. You could then unmount it, which closes the book so to speak, and then mount it some other place. Like /mnt/mydisk. The /mnt folder is by convention the location most disks get mounted. UnRaid mounts all your data disks there. E.g., /mnt/disk1. Now disks are not the only things that can be mounted to a mount point. Suppose you are accessing a remote computer, and want to access its files. In Windows you might refer to a remote share as //mycomputer/sharename. But in Linux you would need to create a mount point and mount that remote share there. You might call it /mnt/sharename. Once mounted, you can access its files. So what else can be mounted? UnRaid has this concept of user shares. They are not real disks, but they sort of look and act like them. So unRaid gives them a mount point and you access them by that mount point. E.g. /mnt/user/Movie. All user shares are in the /mnt/user folder. So let's talk about Dockers for a second. Dockers are interesting little prepackaged units that contain Linux applications. A docker cannot see the disks you have mounted. In fact, a docker has a completely different "root file system" and cannot see anything on your unRaid server. So it can't be mischievous and access files it is not supposed to. But Dockers are built to expect the user will "map" folders from the server file system into the Docker's file system. So the docker can be built to expect its configuration files are in a folder called /config. And you can map your real folder called /user/appdata/appname to the Docker's /config folder. So whenever the docker accesses /config, it is really accessing your appdata user share for the docker. These mappings are called volume mappings. Don't confuse them with mount points although some of the concepts are similar. So what if you didn't, and just left the config folder unmapped. What would happen? Well it would appear to work fine. All of the config data would be stored inside the docker container. But when the docker gets updated in a way that resets the container, all that configuration gets lost and you are back to ground zero. So anything you expect to persist needs to be mapped from locations on your server. The volume mappings vary from docker to docker, but most all have a /config mapping. Getting the mappings right is key to getting Dockers working correctly. Hope that helps. (#ssdindex - mount point basics)
  10. Shares, discs and just general confusion!

    I find it is best to think of user shares as the aggregate of top level directories on each disk. So if you have a folder on disk1 called Movies that contains 5 movies, and a folder of the same name on disk2 with 6 Movies, and a folder on disk3 also with the same name with 8 Movies, and then look at the Movies user share, you will see all 19 Movies in a single folder. UnRaid decides which physical disk to write new files to on the user share with some user share configuration settings. User shares are the heart of unRaid and well worth understanding inside and out.
  11. LCC is the head locking mechanism. Some drives are more aggressive than others. WD is historically the worst. 400 a week honestly would not bother me too much. I am used to seeing them in the tens of thousands. At this rate you'd hit 50,000.on about 2.5 years, and 600,000 in 30 years. I've seen.WD drives over a million in only a few years. And I've never seen a drive die of excessive LCCs.
  12. I have a 7920x! Have not seen any other users on x299! Nice to have someone with similar config! First I would say that the Marvell is a bad idea. Too many problems with drives dropping offline. (See below what to do) If not for that, i'd say your other problem would be easy to fix. Stop the array, assign the NVMe to the cache slot, and restart the array. That should fix the problem with your Dockers. If not, post back and I have some additional ideas. If you have a screenshot of the old array config, you might look at the driveid and compare it to the driveid of the drive as recognized by the new motherboard. Must be a minor difference. The driveid I any referring to is the manufacturer followed by model followed by serial number that is displayed by the gui. The dropped disk is either because of bad cabling or the Marvell. Suggest getting an LSI SAS9201-8i which would only set you back about $50 on eBay. To replace a failed disk, assuming you have not written anything to the array, I would do the following. It is a little involved but not too bad. Install the drive that was kicked as an unassigned device. Mount it and make sure that the contents look good. If they do, unmount, remove as UD, do a new config, assign all the disks to their slots as they were originally, including the.kicked one, click trust parity, and start the array. Check all your disks and make sure all looks good. Then run a correcting parity check. Might find a few sync errors but probably not if you did no writes. Post back with any questions.
  13. I would just say that with unRaid we suggest running monthly parity checks. These are similar to drive rebuilds. If UREs do not occur month after month after month of parity checks, it is extremely unlikely that a drive replacement would generate one. And with dual parity, even one other drive generating a URE could occur and not compromise the rebuild. Raid5 and 6 don't typically run these check cycles (at least I don't think they do). So when a failure occurs, it is trying to rebuild and might be accessing sectors that have not been accessed in many months or longer.
  14. With RAID, TLER is very important. The raid controller is going to expect drives to respond within the TLER time window. No answer and the drive is assumed to have died and gets kicked. So a drive goes to extraordinary effort to retry reads and try to get the data it will very quickly kicked from the array. UnRaid does not care about TLER. It will not kick a drive for responding slowly. So not nearly as important, although NAS drives are fine and work well with unRaid. I would suggest getting a CPU with at least 5000 passmark (preferably 7500). 8G RAM (preferably 12G) and add on controller (LSI SAS9201-8i or similar). I'd also suggest hot swap cages. That will give enough power to serve as NAS server and start to leverage more advanced features like Dockers and even VMs. Because I can promise once you start using it you will come up with use cases you never imagined. UNLESS you already have a motherboard / CPU that you could use to get your feet wet. I'd go with that to get started, and then if you need more, you'll have a much better idea of what to buy. I'd just hate for you to buy something with low power and regret it very soon, when for a few dollars more you could have gotten a more powerful unit.

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.