February 4, 201313 yr Although to be honest, My Work PC is only 32bit Windows 7 Pro (Company requirement/restriction). My development PC for unRAID in running in a VM and is limited to 32bit Guest because of the 32bit Host. This would mean no unRAID testing during my down time in the office. Not a deal breaker though. Virtualbox can run a 64 bit guest in a 32 bit host, as long as the underlying hardware is 64 bit capable.
February 4, 201313 yr ... a dying bread. Sliced? ... and toasted. With Jelly!!! or Mango Chutney spicy please...
February 4, 201313 yr ... a dying bread. Sliced? ... and toasted. With Jelly!!! or Mango Chutney spicy please... Unfortunately, 32bit bread is also stale.
February 4, 201313 yr Wow, that veered off course quickly. And mayhem2408, maybe a 64bit kernel would be good for you. No distractions at the office anymore! ... a dying bread. Sliced? ... and toasted. With Jelly!!! or Mango Chutney spicy please... Unfortunately, 32bit bread is also stale. So its a 32bit crouton now!
February 5, 201313 yr Allright, Allright.. enough loaf-ing around on this, back to the crust of the discussion
February 5, 201313 yr I voted for 64bit specifically for the extra memory that can be supported. Memory is very cheap now. It cost very little to load up a server, assuming you are not needing ECC. More memory would solve a lot of fundamental issues. My opinion is finalize V5. This gives everyone a 32bit solution with a good feature set that they can upgrade too. Move forward with R6 as a 64bit only and back-port/fix critical issues only in R5.x. No more working around the oom killer, at least in reason. Would we still need dirtyable=1 I have to limit the memory during a pre-clear by setting the wrb flags, which significantly slows my pre-clear down. Could implement an RSYNC backup solution. I am thinking about limiting the available memory to 4G to see if that solves some of my issues.
February 5, 201313 yr Hardly anyone's fault, a little humor is always welcomed. Anywho, my train of thought is this: those that want a 64 bit kernel for more memory are interested in New functionality. V5 delivers on this with the plugin system + other additions. Users that don't want/need more than 4 GB are only interested in a solid build that works on older hardware. V5 delivers here as well, the exception being the slow speed issues when using pae. They also want to be able to use bigger harddrives, not currently possible on V4.7. I would say compile the 32 bit kernel occasionally to give support for larger drives, but no porting of new features. Question is, how feasible is this? Using a new kernel can break something else, as we have seen with V5 development. Do you update the kernel until something breaks? One group will be unhappy no matter what the decision is. Going forward it would make sense that even users who are using spare parts will be using 64 bit capable parts as they are by large the norm now. In my mind, if I'm willing to drop $150+ on the newest, largest capacity drive on the market, the extra $150 for a 64 bit system isn't too bad. My entire server, minus drives, is 64 bit capable and cost less than $200. Exclude case and (most likely) powersupply from what would be needed to make the jump to 64 bit, it would be more around $110. I could shave off more if I discounted for the 8 GB ram I put in it and only priced for <4. Keep in mind I'm figuring for the bare essential needed for a user only interested in file serving, no plugins, which would in large be (in my mind) the bulk of the 32 bit crowd. Your in the business of making the best, most capable file serving OS you can. Your move should reflect this. Keep in mind the other thread you commented on about unraid having a dated GUI, making it unappealing to potential buyers. How does the footnote "32 bit only, no more than 4 GB supported" read to you? To me it reads a little dated itself.
February 5, 201313 yr Seriously.... I would like to use my 40 yeard old XT with Windows 8.. Aint gonna happen.. - Version 4.7 will work without speed issues with drives up to 2TB, with a few recognised bugs - Version 5 works without speed issues with a few bandaids (that if Tom would have put them in the base distribution you would not even know about) - Unraid 64 1.0 should work with BTRFS and without memory constraints... Tom mentioned ButterFS, I read up on it, This is basically a completely new way to approach our storage system; possibilities to take drives out of the array without recalculating parity, put drives in, re-balance data on drives, automatic "rollback" to previous versions of files without doing anything special with respect to backups.. Basically "parity" is not even needed anymore, BTRFS works more in a WHS like fashion where it makes sure files are on different drives. Every file that is editted is not CHANGED but copied and saved, this means that as long as you have enough free storage in your array you can revert to previous versions. The whole "bug debate" is a distracter from the way forward. When the speed issue is fixed there will be another thing that is considered a "this is very important Tom, please fix before release". There is no software without bugs. NO software without bugs. The 64bit/BTRFS thing is a much larger improvement functionality wise, it ALSO means we will be moving towards a filesystem that is very actively beiing developped at the moment (so there might be some issues still, its leading edge, no longer bleeding). For those who do not want that; choose between 4.7 and 5.0. Both work and have known issues (and KNOWN is the positive word here). Functionality development on 5.0 should be stopped and a yearly kernel refresh could be done for five more years for those that want it. After that: stay with what is there if you want, or upgrade with possible consequences. In the end there are two types of users I am imagining: - I want to turn this into a home server and it needs to run a lot of stuff I throw at it; these users will upgrade to a newer system anyway, if only for reasons of speed. They will want to use the 64 bit version - Dont mess with perfection, this thing sits in my basement and serves me files; stay on 4.7 and upgrade to 5.0 when you need larger drives. These people will have no need for other functions and do not need to upgrade. For those few people that fall in between both categories: you might have impact, its a shame but cannot be avoided, not everyone can be pleased.. Ofcourse all of this is up to Tom, just my few cents.
February 6, 201313 yr I plan on staying with 32 bit until my motherboard dies. I havent seen anything with 8 on board sata ports that is cheap. Like was just mentioned if all you want is a file server i guess its possible to stick with 5.0, and im sure there are a lot of people using Unraid who are using it because they can re-purpose their old computers - would almost be a shame to cut them off. Im sure alot of the extra tweaks/mods and fixes are also done by people who are on old machines and are looking for ways to tweak every extra little bit of functionality. On the other hand the improvements that are supposedly possible with 64 bit do seem exciting. Guess we're at that point with hardware where its hard to decide whether its time to move on or keep supporting older tech.
February 6, 201313 yr Seriously.... I would like to use my 40 yeard old XT with Windows 8.. Aint gonna happen.. The XT turns 30 on March 8th. Just saying. (previous XT owner)
February 7, 201313 yr im sure there are a lot of people using Unraid who are using it because they can re-purpose their old computers - would almost be a shame to cut them off. That's the point though, these days most old PCs are already going to be 64 bit compatible.
February 7, 201313 yr I did a bit of research... AMD released their 64 bit processors in 2003. In response, Intel released the Pentium 4 and Xeon processors in 2004. So basically, we are looking at computers built before 2005 (or 2006, if it was the-bottom-of-the-line) to find one that won't support a 64 bit OS... My test bed was built in 2006 (and it was the absolute bottom) and it is 64 bit capable.
February 13, 201313 yr I would be interested to see a list of the type of CPUs people are running that are not 64bit capable. Are they all ancient or was there some modern CPU that is 32bit only i.e some low power option
February 13, 201313 yr I would be interested to see a list of the type of CPUs people are running that are not 64bit capable. Not running unRAID, but I have two Core Duo (Yonah) systems purchased in November 2007. I don't know how long this architecture was marketed for (not very long, I understand), but it was superseded by the 64bit Merom/Allendale architecture in June 2007. I think it unlikely that there are many 32bit systems less than five years old.
February 13, 201313 yr Yeah my worry was there was some low power CPU that could very well be 32bit but modern and used more than we suspect. I am of the strong opinion that the next releases of unRAID (which should still be 32bit) have a message on the emHTTP home screen saying "Your system is not 64 bit capable. Please report this to..." Rather than try and get specs on everyone get the people who will have problems to report it early.
February 25, 201313 yr Author Voting has tailed off, so time for a wrap-up. I have to start with an apology for a poorly designed poll. I started with a simple question, whether to stay with 32bit, move future releases to 64bit, or maintain builds of both. That is essentially an opinion poll, so I started trying to craft the poll entries toward a more data-gathering strategy, how many users are 64bit capable and how many really need 32bit support, a fundamental change that polluted the usefulness of the poll. Then I tried to get clever and craft it so that you could both determine the strength of the desire for 64bit on one hand, and on the other how soft the 32bit need was! Lessons learned? 1. Designing a good poll is harder than it looks! 2. Keep it simple, keep it clear and unambiguous; don't try and be clever! There are some things to learn however. For one thing when the poll started, moving to 64bit was actually still a question, and within a just a few days, that was no longer in question. The comments and the obvious consensus made it very clear that we are going to 64bit, and the only question left was whether there would be any further 32bit development. And I think Tom has answered that very well with his suggestion of creating future releases with both 32bit and 64bit builds. That should not be much extra effort, as I believe it will only mean re-running the build process a second time with different switches, plus the additional file upload and notification. Thank you all for voting, and for all the comments.
February 25, 201313 yr Yeah my worry was there was some low power CPU that could very well be 32bit but modern and used more than we suspect. I am of the strong opinion that the next releases of unRAID (which should still be 32bit) have a message on the emHTTP home screen saying "Your system is not 64 bit capable. Please report this to..." Rather than try and get specs on everyone get the people who will have problems to report it early. I know I'm a rarity, but I have an unRAID server that was physically constructed by Tom using the original Intel motherboard he specified for his server. Way back then, he only sold completed machines. It is a PCI bus based machine, with mostly IDE drives and an aging Celeron processor that is most definitely not 64 bit capable. I'm not sure how many servers Tom shipped prior to mine, but I'll bet it was not that many. The unRAID software was shipped on a 128Meg flash drive. If Tom sees a need to progress forward with only a 64 bit build, I'll understand... That older server will just stay on the 4.7 release. ( That original unRAID server has gone from version 1 of unRAID to 4.7 over nearly 8 years.) I doubt if I'll upgrade it to 5.X anytime soon... My newer server is on the latest 5.0-rc11 release and is used to serve media to my home... The older server basically does everything it needs to do and now serves as my backup server. (I would not spend a lot on a replacement IDE disk in it, and today IDE disks are far more expensive than their SATA equivalents. At some point, maybe I'll treat the old server to a new motherboard...) Joe L.
February 25, 201313 yr It is a PCI bus based machine, with mostly IDE drives and an aging Celeron processor that is most definitely not 64 bit capable. I'm not sure how many servers Tom shipped prior to mine, but I'll bet it was not that many. ... and of those, how many are still in use - they could probably be counted on the fingers of no hands!
February 25, 201313 yr It is a PCI bus based machine, with mostly IDE drives and an aging Celeron processor that is most definitely not 64 bit capable. I'm not sure how many servers Tom shipped prior to mine, but I'll bet it was not that many. ... and of those, how many are still in use - they could probably be counted on the fingers of no hands! seeing that initial sales were limited by Tom's ability to physically construct, test and ship, not too many (It was prior to the "free" version of unRAID and prior to the current licensing model.). Who knows, there might be more than you think. Let's guess it was probably less than a few hundred. The fact that unRAID does not need a high powered CPU or a lot of memory when performing its originally designed task means I had no need to update the motherboard. That server has been remarkably stable with the only issue being found early in its life (an intermittent power splitter feeding a set of drive trays) I'm sure some have never been updated from its original OS, or updated only when "user-shares" were added as a feature. The key part of my prior post is that if unRAID were to go to a 64bit model, I would not be unhappy, as I have absolutely no need to update that older server past the last of the 32 bit versions of unRAID. It only has 512 Meg of RAM, in 4 128 Meg memory strips at that. There is no need for extended memory addressing, it doesn't have memory to extend and I don't run memory hogging add-ons. Basically, there is no reason or need to update its OS to 64 bit. Joe L.
March 19, 201313 yr Since V5 supports larger drives I would keep that version at 32bit. You can't leave V4.7 as the last 32bit version, it doesn't even support 3TB drives. Feature lock the V5 final and just update only core/critical. Going forward build out on a 64bit platform with version 6, which is the perfect number to start off with the 64bit version. Get it. 6 for 64bit?
March 19, 201313 yr Going forward build out on a 64bit platform with version 6, which is the perfect number to start off with the 64bit version. Get it. 6 for 64bit? [woosh] Huh [/woosh] >;-)
Archived
This topic is now archived and is closed to further replies.