limetech

Guys we're on thin ice here with this topic. You are only permitted to create a OS X/MacOS VM in unRAID running on Apple hardware only! To do otherwise breaks the terms of their EULA and the last thing we need is a haunting by the ghost of steve jobs. Please don't include the "osk" key or anything about using non-Apple h/w. Cheers, Tom

See also: http://lime-technology.com/forum/index.php?topic=55116.0

Yes, or can send email directly to me: [email protected]

That's good info, thanks. I'm still a bit worried about Parity updates slowing down the writes even with TRIM. This is because with those DZ_TRIM devices we can treat TRIM like a "WRITE all zeros" and update parity accordingly, but probably Parity will not be all zeros. A refinement would be to check if data to be written to Parity is all-zeros and if so, instead doing actual write, send down TRIM instead. Not sure how this would affect performance, I think TRIM is one of those commands that causes a queue draining, which may also impact performance.

A file system issues TRIM commands as a result of deleting a file to tell the ssd that the set of blocks which previously made up the file are no longer being used. The sdd can then mark those blocks as 'free'. Later when the ssd internal garbage collection runs, then it knows that it doesn't have to preserve the contents of those blocks. This makes garbage collection more efficient. There are lots of articles that explain this. The trouble this causes for parity-based array organizations is that the data returned from a TRIM'ed data block can be indeterminate. This paper is a bit wordy but lays it out on p. 13: To boil this down for unRAID: it should work to use SSD's in an unRaid P or P+Q array if TRIM is not used. This is current behavior. However note that: a) Write performance can degrade faster on data disks depending on how many file deletions take place. b) The parity disk is also written for each data disk write. c) The data disks really should be completely written first because theoretically a block that was never written from the point of view of the SSD, can return non-deterministic data for those blocks. We have not seen this happen, but then again we have not run too many SSD arrays (it would show up as parity sync errors). This is pretty undesirable thing to do however since it will guarantee slowing down subsequent writes. d) If you don't want to pre-write the disks as above, then only use SSD's that support "DX_TRIM" or "DZ_TRIM", and instead of writing the disks with zeros, simply use 'blkdisard' command to first TRIM the entire device instead. You can use the 'hdparm' command to determine if your SSD's have this support: hdparm -I /dev/sdX # substitute X for your ssd device assignment You want to look near the end of the "Commands/features:" section for: * Data Set Management TRIM supported Following this will either see this: * Deterministic read data after TRIM or you will see this: * Deterministic read zeros after TRIM or you won't see either of the above (if this is the case, do not use in unRAID P or P+Q array). In a future release we do plan to add proper TRIM support to array disks. Here's a heads-up on that. In order to support TRIM in unRaid P or P+Q array, we must add code to the md/unraid driver and all SSD's in the array must support either "DX_TRIM" or "DZ_TRIM" mode as described above. In addition there's a really good chance we will only support SSD's that support "DZ_TRIM" since to support "DX_TRIM" is a lot more work

After it shows "expired" in the upper left of the header, nothing actually happens until you Stop the array. You will find that you cannot then Start the array again with an expired key, but in this state when go to the Registration page, now a button shows up where you can get an extension. Yes the way it works right now is a bit confusing and we will be changing it...

For the record: we here at Lime Technology are agnostic when it comes to file systems and we welcome discussion. However this is a requirement: no fanboi flame wars. You want to talk about technical advantages/disadvantages, go for it! But if you just want to say, "I read somewhere xxx sucks, don't use it!" well there are plenty of other places to do that. Here are the main reasons we went with btrfs for the cache pool (vs other multi-device capable file systems): 1. Docker support. When we first integrated Docker they didn't offer zfs support, but did offer btrfs, though these days I think they do support zfs now. 2. The h/w requirements to smoothly run zfs are quite onerous for a consumer NAS, though that too is less important. 3. The licensing was/is still an issue and we didn't feel like paying our lawyer 4 figures to give us the definitive answer of whether we can bundle zfs with unRAID OS, and we didn't want to go the "Guide" route instructing our customers to download zfs themselves in order to use a fundamental feature of the product. 4. Questionable linux integration. zfs remains a third party component which is not updated in step with the linux kernel, which also means it's not tested alongside other kernel components during ongoing kernel development. We never want to get into a situation where we have to update the kernel to address a serious bug or security issue, but can't update because it breaks another key component. I guess there are other lessor reasons for using btrfs. For example, personally I have studied quite a bit of the code base, and we are familiar with how it works and how to use the management tools. Probably the way we will approach this moving forward is to develop better plugin/snapin support in unRAID OS to make it easier for many kinds of third party components to be integrated with unRAID OS.

iSCSI is a block-level protocol. How should an iSCSI LUN be mapped to unRAID storage? The only use case I can see for this is a SAN.

Good question. What's the use case for iSCSI?

Have you tried 6.3.0-rc3?

The reason the mover is so slow is that for each and every file it must check if that file is "in use" before trying to move it from source to destination. This is because there is no concept of "automatic file locking" - it's completely possible for one process to read a file that another process is writing. The "in use" test is pretty expensive.

Ok probably have to do a pkill find as well. Never had to stop the mover before. We'll see about adding some kind of cancel control. Not really recommended though. Why do you want to cancel it?

pkill mover That will kill the script, but important to let the current copy complete.

It appears the Dell branded controllers use custom firmware (for Dell) and it's not possible to "flash" them into "IT mode". The closest you get to JBOD is to configure it so that each device is in single-device raid0. But we are still looking into this.

Actually we're working with someone else to try and support that controller. Should have more info on this early next week. Send me an email: [email protected] and we'll try and keep you up to date on this.

Key sent. Sorry for the delay.

We have received your email requests and have replied to them all, and your replacement key was sent. But obviously you are not receiving email from us. Check your PM.

Send your second USB Flash GUID to me: [email protected]

There is no more 'call home' starting in 6.2.0-rc5 unless you are using a Trial key. Trial will always require internet access in order to validate. If you want to stay on "stable" releases, you won't have to do anything: the built-in "unRAIDServer.plg" file will trigger updates whenever a new stable release is available. We will also create a post in the Announcement board for new stable releases. If you want to use the latest and greatest development, you will install the "unRAIDServer-next.plg" file. This will trigger updates whenever a new development release is available. We will typically not post announcements for these releases. We will provide more details upon release of 6.2 stable.

We have updated our Policies page with more details regarding Privacy: https://lime-technology.com/policies/

We are going to clear this up by abandoning the notions of "beta" and "rc" starting with next release after 6.2.

Not going to happen. Once 6.2 'stable' is released, 6.1 is no longer supported. We simply don't have the resources to maintain multiple release trees.

I want to apologize for doing a piss poor job of keeping 6.1.x "latest stable" up to date with regards to CVE's. We were doing ok until sometime after March 4, 2016 when 6.1.9 was released. We fully expected 6.2 to be released soon thereafter. But one thing led to another, and 6.2 has been drug out much longer and in the interim we quit updating the 6.1.x branch because, well, "we are always very close to releasing 6.2". This will be in the 6.2-rc5 announcement post as well, but here is our plan. We will release 6.2.0-rc5 and barring a show-stopper, that will be the last -rc, and then we will release 6.2 'stable' with nothing more significant than a version number change. There will be some "known issues" in 6.2 which will be addressed in 6.2.1, but as of now, it will not be productive for us to generate a 6.1.10 and then within days release 6.2. I hope everyone understands, and we as a team really do take security seriously, though I can see it might not look that way. We are committed to getting more proactive in this area, but as they say, talk is cheap. I know there are several long time unRAID users who will hold our feet to the fire.

With the integration of bonienl's excellent advanced networking features, the server network settings are now reported via: /var/local/emhttp/network.ini There are a number of variables passed in /var/local/emhttp/var.ini which are now deprecated and will be removed in the unRAID OS 6.2 "stable" release. If this affects your plugin, please make appropriate adjustments. Here is the list of variables which will be removed from /var/local/emhttp/var.ini : USE_DHCP IPADDR NETMASK GATEWAY HWADDR DHCP_KEEPRESOLV DNS_SERVER1 DNS_SERVER2 DNS_SERVER3 BONDING BONDING_MODE BRIDGING BRNAME BRSTP BRFD MTU

At present we are maintaining two code branches: latest stable and development. The latest stable is always the first entry listed under Stable Releases on the website Download page. The development releases are only publicized in the forum Announcement board. If a relevant Slackware Security Advisory package update becomes available (or other kind of security update), we update both the latest stable and development branches. For the latest stable branch, we then increment the patch level of the release version (the third digit) and publish the new release as soon as practical. Other critical bug fixes may also trigger publishing another latest stable patch release. Of the stable releases listed on the Download page, only the latest stable will be updated. That is, we do not maintain multiple old stable releases at this time. Updates are free and users are encouraged to keep up-to-date. For the development branch, an updated release may or may not be published at the same time as the new stable release, but any package updates or bug fixes which go into latest stable are first integrated into development and tested. Anyone who discovers a security-related issue is encouraged to post here so that we can integrate necessary patches in a timely manner.