UnRAID 32bit vs 64bit poll

[RobJ]

Just a note about voting, you can change your vote, but the mechanism is a little odd.  You first select the REMOVE VOTE option below the poll results, then you can vote again.

[WeeboTech]

I could produce two kernels with each build:

- a non-PAE 32-bit kernel

- an x86_64 kernel

 

BTW, current kernel as PAE-capable 32-bit but I've always thought PAE is a hack.

 

I like this idea, but it means more work for you.

 

I would have to add that in the past, the PAE setting caused me grief when I tried to run unRAID on certain pentium M or celeron processors. I had to recompile the kernel to remove the PAE setting, then everything worked fine. So removing PAE for 32bit 4GB systems seems like a good idea if you are willing to maintain the two kernels.

[UhClem]

...

I guess the real question is are older (presumably 32-bit) applications still able to be used?

Yes--providing that the 32-bit libraries+compatibility package is installed. Since LimeTech has already mentioned this, I'm sure it won't be omitted from the 64-bit distribution.

 

[wsume99]

I could produce two kernels with each build:

- a non-PAE 32-bit kernel

- an x86_64 kernel

 

BTW, current kernel as PAE-capable 32-bit but I've always thought PAE is a hack.

 

I like this idea, but it means more work for you.

That is why I don't like the idea. With all the gripes over the past several months about the delay in releasing v5 does it really make sense to now start maintaining two builds? Just to be clear - I'm not griping but rather pointing out the fact that many users are not happy with the rate of progress. So far the poll results are pretty clear that there is not a big need for 32-bit capability. Maybe v5.0 should be the last build with 32-bit capability and going forward it should be 64-bit only?

[jbartlett]

I'd be happy with a 64bit only version going forward as long as the 32bit version received any critical updates if such a need comes up. In theory, that should keep people with 32bit systems happy until they are willing to upgrade.

[StevenD]

I could produce two kernels with each build:

- a non-PAE 32-bit kernel

- an x86_64 kernel

 

BTW, current kernel as PAE-capable 32-bit but I've always thought PAE is a hack.

 

I like this idea, but it means more work for you.

Maybe v5.0 should be the last build with 32-bit capability and going forward it should be 64-bit only?

 

This was my thought on the subject.

 

[SavellM]

Any idea when unRAID will become 64bit, or have a 64bit installer?

[Zonediver]

Hmmm - maybe a silly Question, but is unRAID 32bit???

I use 8GB RAM since a long time and when i have a look on iStat it shows me 8GB are almost full.

How can a 32bit SYS adress 8GB of RAM? Strange

So i thought, it is already 64bit - but maybe, i am wrong 

[JonathanM]

Hmmm - maybe a silly Question, but is unRAID 32bit???

How can a 32bit SYS adress 8GB of RAM? Strange

It's 32bit with PAE

[dirtysanchez]

64-bit capable, and I'd like to move there in the future, but it isn't something that's needed NOW IMO.

[PeterB]

64-bit capable, and I'd like to move there in the future, but it isn't something that's needed NOW IMO.

 

... unless it resolves the issues that some users have!

[dirtysanchez]

64-bit capable, and I'd like to move there in the future, but it isn't something that's needed NOW IMO.

 

... unless it resolves the issues that some users have!

 

Fair enough.  I certainly wouldn't be happy if my write speeds were 1MBps.  Perhaps I should have said "it isn't something that's needed NOW for me". 

 

That said, I am also personally of the opinion that 5.0 final should be released as long as it's stable, even if it has issues with a small subset of hardware (you just can't make it flawless across so much varying hardware).  All future development should then focus on 64-bit.

[PeterB]

... 5.0 final should be released as long as it's stable, even if it has issues with a small subset of hardware ...

 

Yes, I would agree with that, but ....

 

I don't think that anyone knows the how big that subset is.  Some people with non-Supermicro boards are reporting a similar problem while some X9SCM users claim that they are not affected (including Tom?).  Can we be sure that they're using the same criteria to determine whether they are affected?  Perhaps it's not the mobo, or chipset ... maybe it's the Xeon processor (V1 or V2?)?  Maybe it's dependant on the type of RAM installed, or a SATA interface, or BIOS version or....?

 

I think that Tom would be ill-advised to release before precisely identifying the culprit.

[bobbintb]

personally, i am looking forward to 64-bit because, like Tom, i feel PAE is kind of a workaround hack and i tend to dislike those. it seems most people are either indifferent or prefer to move forward with 64bit. of the 192 that took the poll, only 3 use 32 bit hardware (two of which are ok retiring it). and from the comments some of those may have even been mistaken. it seems like going forward with 64-bit is the way things may be going. if that is the case then the question changes to what to do about 32 support.

 

in my view, there are 4 options in regards to this happening:

1. drop support for 32bit. make 4.x the last of the 32bit line

2. fully support both versions indefinitely

3. fully support both versions for a while (i.e. through 5.x). the phase out approach.

4. legacy support 32-bit with only critical bug fixes (feature locked).

[PeterB]

1. drop support for 32bit. make 4.x the last of the 32bit line

 

That would dictate that v5 is not released before 64bit is implemented and beta tested.  This, I suspect, would impose a delay othe v5 release which would not be acceptable to many.

 

2. fully support both versions indefinitely

 

Probably not necessary.

 

3. fully support both versions for a while (i.e. through 5.x). the phase out approach.

 

This is probably the best plan, possibly with:

 

4. legacy support 32-bit with only critical bug fixes (feature locked).

thereafter.

 

However, only Tom can gauge how much extra effort would be required to support 32 bit and 64 bit simultaneously.

[kleptonite]

My vote would be for only 1 version of unRAID to be maintained.

 

And if 64bit were to be chosen, I wouldn't want it to impact in any way on the release of 5.0 Final.

 

Are the applications we commonly use on unRAID already 64bit compliant? How many of them would potentially benefit from the move?

[PeterB]

My vote would be for only 1 version of unRAID to be maintained.

 

I would vote for a 64bit future but, where necessary and possible, bug fixes should be backported to the 32bit version.  However, as development of the current sources continues, this would become more and more difficult, so a line would have to be drawn somewhere.

 

And if 64bit were to be chosen, I wouldn't want it to impact in any way on the release of 5.0 Final.

 

I believe that, in order to maintain credibility, further delays to the v5 release should be avoided.

 

Are the applications we commonly use on unRAID already 64bit compliant? How many of them would potentially benefit from the move?

 

Most/all binary code which we add to unRAID is 32bit and will only work in a 64bit environment if the 32bit compatibility libraries are included.  Ultimately, we should be looking to use only 64bit binaries.  It's not so much that individual applications will benefit, but that the whole system will be smoother if we remove the 32bit restrictions.

[electron286]

  The poll did not have the answer I would have picked...  MAINTAIN BOTH 32 and 64 bit versions...  I have MOST of my unRAID servers on OLDER (much) hardware before 64 bit capability.  When testing I usually start with a really old hardware platform, to make basic benchmarking and reliability testing on a build before moving it up to a newer final destination test bed...

 

  (I also do that with other OS builds to see quickly what limits the OS will run within, so I know what to expect with much more capable hardware when advancing to later test stages) (MS really messed me up with the requirement of the Execution Disable Bit in Win8... I had to go back and re-test many levels of prior releases on a much newer, far too capable hardware machine for a bench-mark trend line... )

 

  I do see that eventually it probably will make sense to make a switch over to 64-bit exclusive for new builds...  BUT I would hope then that the older 4.x might still recieve periodoc updates as needed to allow newer bigger hard-drives for example, to allow upgrades without requiring CPU and MB replacements...  (just an example of why a 32-bit version would need to still be updated here and there...)  Other new features, such as mult-cache and parity drives, or what-ever may seem to be good to put into future versions may be good to only place in a future 64-bit developement path, but hardware updates to allow newer hardware for incremental system updates should be available on both 64-bit, and a possibly other-wise locked 32-bit version which may never see new features beyond a specified point.

 

  This way, in the future, a person could still grab old hardware, or a combination of new and old, such as a set of drives that are larger than what is even NOW available with an old PIII, P4, Atholn, Duron, or so CPU and MB, for cheap or free, and make it a very usable unRAID server, even if it is not as feature rich as a newer on-going developed 64-bit version may then be...

 

  Just my thoughts.  I like to show that even my ancient hardware can still be used  for really cool things, such as redundant backups(read unRAID) and SETI@home...  :-)

 

[lishpy]

I have a 64bit capable server, but honestly I could care less. I've been running the same server for years now (other than swapping a MOBO) and I'm still running a Sempron with 1GB of RAM. I have zero issues with server performance, so I don't see the need for 64-bit, at least for me. I could see if I was trying to run Plex Media Server or something directly from my server, but I use it as a file server and nothing else. It's definitely the future, I just don't know if it's what's needed at this moment.

[dwoods99]

Maybe v5.0 should be the last build with 32-bit capability and going forward it should be 64-bit only?

 

This was my thought on the subject.

 

Same for me.

Put out a final 5.0 and make 5.5 or 6.0 64-bit version.

However 5.0 (32-bit) only gets major bug fixes or security issues for updates... and that's where 32-bit support stops.

 

This ensures a good unRaid version with 2TB+ support and ntfs/ext3 (USB mounting) support on older 32-bit hardware, which 4.7 does not support.

 

 

[pantheis]

This may seem to be an odd reason for wanting 64bit, but I run VirtualBox VM on my unRaid box so I can run an Ubuntu 12.04 LTS server VM, in which I run a Minecraft server along with Jenkins. I currently have 4GB of ram on the system and would very much love to have more. The VM instance gets 2.5GB of the 4GB available and that makes things a little tight (Minecraft is a memory hog).

 

I would love to have a 64 bit unRaid OS so I could use a 64 bit Ubuntu VM instance and add more RAM to my server to use without resorting to PAE. As you can imagine, with all of the above stuff, I've made some major mods to the unRaid side of the house and would need to set things back up again under version 5. I'm waiting to do that until a 64 bit version is available.

 

[mayhem2408]

Would I be correct in saying that a 64bit version will require 64bit library's. My limited understanding of the Linux kernel is that 32bit apps and librarys will not run on a 64bit kernel. Unlike Windows which can run 32bit apps in the 64bit OS. Is this correct. If it is correct, I will need 32bit for quiet some time to come.

[BRiT]

No, you would be incorrect. You can install the 32bit compatibility libraries and will be able to run all the 32bit software you want that resides in user-land.

 

This is the step 'install multilib for Slackware x86_64'  from my writeup (http://lime-technology.com/forum/index.php?topic=5639.0) on this from 2010.

[speeding_ant]

The 64-bit kernels for x86_64 offer both a 64-bit and a 32-bit kernel ABI (application binary interface). The latter is identical with the ABI for the corresponding 32-bit kernel. This means that the 32-bit application can communicate with the 64-bit kernel in the same way as with the 32-bit kernel.

 

The 32-bit emulation of system calls for a 64-bit kernel does not support all the APIs used by system programs. This depends on the platform. For this reason, a small number of applications, like lspci, must be compiled.

 

A 64-bit kernel can only load 64-bit kernel modules that have been specially compiled for this kernel. It is not possible to use 32-bit kernel modules.

 

Essentially anything that requires it's own kernel driver will need to be 64-bit, or calls something that doesn't have an open architecture. Otherwise any 32-bit binary will work as expected.

[mayhem2408]

Thanks speeding_ant and BRiT

 

Based on that info, a 64bit only version would be fine. The 32bit version would only be useful for older CPU configs. But I'm guessing more and more people are wanting to install more and more plugins and the older CPU configs are a dying bread. Otherwise there would be no question of even needing a 64bit version as unRAID by itself doesn't come close to hitting the limits of 32bit.

 

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.