jaybee

Members
  • Posts

    249
  • Joined

  • Last visited

Everything posted by jaybee

  1. Questions about DSM: What is the maximum number of disks it can support? I take it disks cannot spin down as it is RAID5 based? Does it support hot spares? Does it support 2 disk failures? Can it be expanded easily? I think yes as it features "hybrid raid". What happens if your hardware fails as opposed to the disks failing..how do you get backonline if at all?
  2. Limtech can you update with status of 5 FINAL?
  3. A quick google suggests the DS1813+ is around £1000 to buy here in the UK. That's about $1500. That's bare with no drives. Let's say we build the same unraid server with the same amount of drives so we will write off the cost of drives and just focus on machine costs. You can build an unraid server that functions the same for a lot less. You can in fact build one that functions to arguably an acceptable standard for its main intended use as a media streaming server for very little, using older - often recycled - parts. I would argue that you could buy an old machine/server second hand for under £50/$50 and it work ok. But let's be fair and assume we want something modern and reasonably powered for an unraid server. I would take my machine as a good example. Modern USB3 Intel Motherboard, low spec (but adequate) Intel Dual Core CPU, 4gb RAM, my old PSU reused, second hand huge case. This all cost me easily under £200. It's really whether you can afford to pay a price premium for the ease of plug and play, and the electricity bill/heat/noise of constantly running 8 drives. Different situations call for different things. I would also worry as somebody had already pointed out, that the internals (not the disk drives) can fail, leaving you a difficult recovery. If the Synology product used a one off bespoke RAID controller/card custom made for/by Synology, then the only way to get your drives back up and running under the same RAID array would be to buy the same product again or if it is end of life, to speak to Synology and see what they can offer you. Potentially problematic. If your unraid server dies you can be up and running very easily with new hardware. If your USB drive fails you can move your drives externally to another Linux Resier FS server and pull the data off. I cannot see any products that have come out that can spin down the drives like unraid, and do not limit the user to X number of drives, and do not limit the capacity of the total storage array not being able to expand drive sizes. Essentially these products commercially are based on RAID5. This is the problem. We are talking about the limitations of RAID5 commerical products. Nobody has made a real unraid competitor yet because we are talking about software level improvements first, and this comes so far only with indy outfits like unraid and flexraid.
  4. Agree. I looked at flex a while ago and then settled on unraid due to - somewhat ironically - the support looked better.
  5. I know this won't go down well with all, but I have to say it. It's bad enough with the lack of updates and time it has taken to get 5 to final (still waiting). It's bad enough that when Tom puts a release live it's instantly replaced by an "A" or "B" designation due to a rushed effort. It's bad enough that the site has been hacked before and the download links are often down. But to be hacked AGAIN, and the mods chasing the owner of said business to see if he can fix it whilst apparently being AWOL (again)... nice and professional around here still I see. For someone in the business of making and supporting unraid, I would think it would not be a tall order to expect them to be able to invest in some decent web hosting. Joke outfit at times here.
  6. They release a product which is their best effort at attempting a finalized product. At the moment we have not had this for version 5. We have only had BETA and RC builds. If RC11 is final, it would have been called this already. The naming of the final RC to final is a big step as it is a statement from Tom that he is happy and convinced that with all the testing on it, it is ready to be named so and there are no known bugs with the version.
  7. Is this the same one where initially people thought it was to do with running more than 4gb of ram? I thought only a small number of setups were affected? It's a bit of a shame that over 80% of people voted that version 5 FINAL was ready for release, and yet here we are still waiting for a bug to be fixed. I had high hopes that Tom would integrate all the minor last things together and release 5 FINAL with a note that it was compatible only for <4gb of ram setups.
  8. Tom, can we get an update from you?
  9. So are we having a 5 FINAL? This seems to have dropped off the radar somewhat. Are we still in a testing phase of the current RC11 and/or RC11a? What's happening. Again it's gone quiet.
  10. Why do you think this is a problem with RC11? It look like a hardware issue as you say yourself?
  11. Unlikely! Plugin support didn't arrive until v5.0b11. I think maybe we are talking about different things? I'm not talking about a plugin manager, I'm talking about the actual plugins working on different versions. You can't mean that all plugins for unraid were written for or after version 5.0b11, as that is how it reads.
  12. Interesting. I am a bit concerned with plugin support though. There are a couple of plugins I used when I first installed unraid to test which I consider essential, and a lot of these were written around version 4.7. We keep seeing posts where plugins break each time we upgrade. Is it going to become problematic in having good availability of plugins that support 4.7, 5.0, 5.1 and/or the newer 64bit kernel going forward? I hope not. I think there comes a time when you have to be quite ruthless and say it is time to move on, and only support hardware/configuration XYZ. I mean, the people that are saying they are going to be left behind with non compatible 32bit hardware.... this is 2013. I would hazard a guess that the majority of people that post here and are into unraid can pluck up some money to afford a 64bit compatible board/cpu. You can buy an old system that would be suitable for less than the cost of an unraid licence I suspect. If we keep trying to support everything and make unraid so universally compatible, it will never move on. If the slow write issue is because of running more than 4gb of ram. I think 5 should be released and specified as only compatible with 4gb max of ram. Ram is cheap. Worst case is some people have to buy a couple of sticks to facilitate their needs. Anymore problems with crappy realtek nics for example should be met with a reluctance to keep supporting them and only Intel NICs supported. I say this owning a board WITH a realtek NIC. I am finding it a bit disappointing to keep seeing RC after RC and then after a few posts a statement from Tom like "fixed in next RC". It feels like this will continue forever right now. ( Additionally, Tom, you started a thread asking us our opinion on whether 5 should be released as is, and for the entire duration of the thread when I looked at the poll results, it always maintained an above 80% agreement in favour of releasing FINAL as is. Despite this, you are chosing to delay it further, but you have explained why and I think another week cannot hurt. It just feels like we say this a lot. "Just one more..."
  13. So Tom what are you thoughts? I have not seen you reply in this thread for a while, if at all.
  14. I do not know what this cache_dirs thing is? Can someone explain this to me? Are you saying without this plugin installed, the core functionality of unraid to spin down and up drives does not work? That is how it reads and I find that hard to believe.
  15. 4.7 only had support for <2TB drives though which is where this problem was first experienced no?
  16. I thought "bug 3" mentioned above was already fixed in an earlier 5 Beta personally. I was certainly under the impression that all known 4.7 issues were addressed and now non issues in version 5 betas and RC's. Perhaps Tom can confirm. I'm not sure I fully understand the bug anyway to be honest. It sounds like it would only affect someone who's USB stick dies or corrupts?
  17. It would have been nice if you linked or wrote the information that you found, as I am sure a lot of others will start to ask the same questions. I am unsure on this myself and currently have 4.7 on my USB.
  18. Is it worth rewriting the entire USB drive out from scratch plus permissions script and then seeing how you get on?
  19. There are a couple of minor bugs Tom wanted to "fix for final". I'm not sure if he will do this, or create one final RC just to ensure nothing pops up with any changes. They were: Very good point. I'll fix that for final. Harmless bug, I'll fix for 'final'. There was also the thing with new permissions script and/or writing out to the USB drive again is required. Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.
  20. It's not "just a name change". Please stop going down that road. Calling this long awaited version 5 release final has huge implications. It basically publicly states that a new build has finally been deemed stable and bug free enough to be the new recommended and default main build of unraid for all to use. I don't really see the write bug as a huge issue right now until some more people report it. That thread needs more input. A list needs to be made of everyone reporting the issue and their hardware specs, specifically including the amount of ram present and any customizations running. I think if a decision has to be made now, release it. If Tom is happy to wait - and I know this could go on forever - then I think a couple more weeks won't hurt given that this write speed bug seems to be fairly specific and one main area to look at, rather than lots of little bugs.
  21. I voted to release it. The main reason is that we have still had no statement about fixing 4.7 issues. I assume Tom, that these will not be fixed as your efforts are focused on getting 5 FINAL as priority. There is currently to my eyes no official FINAL stable version out there. Version 5 FINAL needs to happen asap, even if it means compromising a little. Of the options presented, I agree a 64bit kernel is the ongoing route I would like to see, but this is not something to be doing now just because a few users have mentioned a slow write bug. With this thinking, 5 would never go final. There will always be something. Catering for so much hardware is your own worst enemy sometimes. I think you need to be more ruthless and state that XYZ ONLY are supported if need be. i.e. If it were me, I would have just given up realtek NIC support ages ago and said to people only Intel NICs are supported. I say that as someone that owns a board with a realtek on board NIC, but would quite happily pay and install an Intel one knowing they cause a lot less issues and are better performance typically anyway. It looks like the "write bug" only seems to affect some people anyway, and as said, people with larger amounts of ram (over 4gb). If this really is the only major bug - and all other minor ones mentioned are indeed fixed like you said they will be for FINAL - then I think the time is now. 4.7 has bugs and lack of support for modern drives. We need a release ASAP. That's the bottom line. I appreciate the hard work you have put into this by the way. What ever your decision going forward with 5.1/6.0 or whatever, we need some kind of road map or prediction of ETAs and/or a promise of what communication updates we will get to state progress. I would support testing a 64bit kernel if I could facilitate it. Thanks
  22. This includes the fix that was going to be in RC9b as well doesn't it. Good times. So....this is it then. Assuming all goes well with this over the next week, this will become version 5 final. Exciting for the community.
  23. Thanks for the replies. You have put my mind at ease slightly. I am happy with all responses except point 1. I'm still not really feeling the whole "just use current stuff" mentality. As you say, you fix something and then something else breaks... Anyway, ETA for RC9b? It sounds to me from the above - and I'm thinking this could be too good to be true - that the only current known bug/issue is the one which will be fixed in RC9b? Correct? Good work. About time I have to say though. EDIT1: Oh and I do have a realtek ethernet port. I have looked at getting an Intel card but never got round to it. EDIT2: The point about you leaving bugs in so the whole community sees it... I didn't mean it like that. Of course I appreciate fixing new things is good, but on an RC number 9... it makes me feel like given enough time, you would go on spotting bugs indefinitely - which may be the case with any software - but it does not really inspire confidence when we are this close to 5 final and still newer stuff is being found. That is all I meant. Maybe it is time to be stubborn and change the minimum possible?
  24. My concerns are as follows. 1: An RC by definition is typically very close to final and should be pretty locked down, with only minor changes made specifically for fixes. I notice each RC we have a different Kernel version, different SAMBA version, different Realtek driver version. Final will never happen if a constant is not maintained as the introduction of new bugs will be forever ongoing. 2: What happened to the older bugs and issues talked about like NFS stability and parity speeds and file share problems? 3: Bugs have been fixed and further changes made of which we did not even know about until reading the release notes/OP. This does not inspire confidence and relates to point 1 above. 4: There is still apparently a requirement for further work with a bug that needs fixing (RC9b). 5: We instantly required an RC9a and then an RC9b despite that the hope was for this to relabelled "FINAL" after only a week. Again not inspiring confidence. 6: Despite points raised above, we still have no native ability to cleanly shut down the server from the command line. This seems odd to me that this would not be fixed to be native rather than via add ons, especially in light of issues with webgui's hanging and becoming unavailable. 7: The new permissions utility is required to be run after upgrading. This sounds like a bodge fix of an unknown underlying problem, or am I interpreting that wrongly?
  25. So to confirm, we had RC9 and RC9a, but are now waiting on an RC9b? What is the ETA for RC9b?