GlusterFS Planning To Drop 32-Bit Support

[phoronix]

Phoronix: GlusterFS Planning To Drop 32-Bit Support

The GlusterFS network attached storage file-system developed by Red Hat with a focus on cloud computing is the latest open-source project eyeing the removal of 32-bit (i686) software support...

http://www.phoronix.com/scan.php?page=news_item&px=GlusterFS-To-End-32-Bit

[chilinux]

To have a quorum of GlusterFS servers requires at least 3 servers. This requirement to avoid split brain issues makes perfect sense and shouldn't be a big deal for most companies to provide to take advantage of GlusterFS. Also, when looking at competing offerings such as clones of the Amazon S3 protocol, those products also tend to require a minimum of 3 servers.

However, for someone looking to learn about GlusterFS as a home hobby project, the cost for hardware and power can be seen as a large hurtle which might discourage others to get involved. One way around this would be to set up three Raspberry Pi's. However, most of the mainstream install images are 32-bit to provide universal support across all four major versions of the hardware. Once 32-bit support is gutted from GlusterFS, hopefully someone is willing to write up novice friendly documentation on how to continue to use v3 or v4 Pi hardware for playing with GlusterFS.

[R41N3R]

The Pi3 and newer are 64 bit capable, I've used it with Arch Linux Arm. My initial idea was as well to play around with glusterfs there but then I've used normal home computers. Now I run glusterfs with 2 machines, setup was quite easy. As of btrfs I was not worried too much to run into a split brain issue, but it is easy to add one mirror.
The only thing that worries me when running something like glusterfs is the missing auto config for scalability, you really have to make the layout always manual.

[wizard69]

This will likely only impact people trying to do Gluster with low end support Kyle board computers. Even then the number of low end 64bit hardware suitable for such use increase everyday.

As for Raspberry PI .org I think they are being extremely short sighted. There needs to be a real push for a 64 bit distro there.

[microcode]

Not really sure what the mechanism of this is... What part of GlusterFS relies on 64-bit addressing?

[Hibbelharry]

However, for someone looking to learn about GlusterFS as a home hobby project, the cost for hardware and power can be seen as a large hurtle which might discourage others to get involved.

I think gluster was never targeting any hobby audience. It's for the utmost part only useful in cluster environments and clustering is no real prominent hobby project either. If clustering gets to that state in any future, there are financial interests behind the gluster development, and I don't see any profitability from hobbyists. I do use glusterfs at work and whenever I seek for knowledge there is just the audience of mostly professionals. This applies to most clustering related stuff.

So i would state: Hobbyists are no target, they don't matter.

Not really sure what the mechanism of this is... What part of GlusterFS relies on 64-bit addressing?

I think it's more like "why do support if there is no relevant target audience?"

I don't know any datacenters here in europe still relying on 32bit OS, except of some old solaris stuff. I guess that's the same for many other countries.

[polarathene]

Anyone know how GlusterFS compares to Ceph? Ceph afaik is equivalent or better option these days?

[s_j_newbury]

What I find concerning about all this is the apparent disregard for good programming practices. If there is an implementation requirement for an address space >32bit, that is one thing, but just to allow programmers to be sloppy about assumptions so they don't have to use explicitly sized types and structures...? This is only going to result in more bugs, and testing coverage will suffer. Is it just laziness?

Additionally, there's always going to be 32-bit CPUs, even if no more 32-bit x86s ever get made there are many embedded applications that do not require 64-bit where, for example, a hardened 32-bit processor is the right choice, just like there's still 16-bit, and even 8-bit CPUs and microcontrollers still around.

[iker]

It's really bad to see that people are making the same mistakes all over again. Why does a network-filesystem need to be restricted in the bit-ness of the HW/OS?
Since "modern" networking doesn't care if you are an Arduino or some Cray cluster, little or big endian, power or x86, why should a storage solution?

[Hibbelharry]

Anyone know how GlusterFS compares to Ceph? Ceph afaik is equivalent or better option these days?

Good question. I'm also looking for answers on that matter these days.

What I find concerning about all this is the apparent disregard for good programming practices. If there is an implementation requirement for an address space >32bit, that is one thing, but just to allow programmers to be sloppy about assumptions so they don't have to use explicitly sized types and structures...? This is only going to result in more bugs, and testing coverage will suffer. Is it just laziness?

Where did you find the reasoning that 32bit is dropped because of the wish to be able to program more lazy? I think programming practices are no reason here, it's just dropping support for a longtime dead architecture. 32bit is dead in the datacenters.

Additionally, there's always going to be 32-bit CPUs, even if no more 32-bit x86s ever get made there are many embedded applications that do not require 64-bit where, for example, a hardened 32-bit processor is the right choice, just like there's still 16-bit, and even 8-bit CPUs and microcontrollers still around.

That's no target audience for gluster. You will never see clustered refrigerators.