edit: cleanup wording.
With the quashing of the slow metadata performance (http://lwn.net/Articles/476263/), XFS seems to be all-round just as good as ext4 but with more future-proofiness for large volumes. Keep in mind that RHEL releases are supported for around a decade.
I believe the XFS devs (or at least the few I spoke to from the Australian team) all believed XFS was more then ready to replace EXT and should have replaced XFS. I suspect now that EXT4 is showing its age with massive filesystem sizes, that Red Hat is faced with 2 complex file systems. XFS is proven, and reliable. BtrFS is feature rich, evolving, but lacking a proven history with the diversity of systems that Red Hat need to support. Given that, I think going XFS was the expected move by Red Hat... conservative and incremental.
This presentation should be interesting to answer your question: http://rhsummit.files.wordpress.com/2014/04/rwheeler_thursda...
I've always preferred XFS over ext4 on ephemeral cloud instances, because you don't expect it to come back if it crashes.
The small disks of that time and the fact that you weren't running a 'DOS' file system meant that formatting disks for some new partition was par for the course and a regular task. There were GUI tools to make it easy but invariably the command line was how things got done. Clearly there were unusual SGI users that needed 'peta-byte' sized file systems and XFS was designed with those guys in mind. So, one way or another, XFS has been thoroughly tested, the small disks of that time probably helped with that as more disk chores were needed.
I am glad to see some SGI making it into mainstream linux computing.
I'm still scarred by it.
This actually makes me happier with my decision to use FreeBSD and ZFS for a recent file server. I'll still use RHEL/CentOS for client nodes, but they'll all be using the ZFS export for storage.
If you compile your own lame ls implementation and read in say a 1 meg buffer vs 1024 bytes at a time, you can print out directories with over 4 million entries in about a second versus 20ish hours with 1024 byte buffers (yeah I timed it).
I'm not saying ext4 doesn't have issues, just that its not as simple as it seems on the surface.
In any case, the classic workaround (which can be a PITA) is to create a tree of subfolders and distribute files between them. E.g. first letter of filename, second letter of filename, or for more even distribution use first characters from hashing the filename.
Since BTRFS isn't up, they employ XFS people and they use XFS in their Gluster implementation, it's easier for them to test/support it and push Redhat Enterprise Storage Server out to folks. I wouldn't be surprised if we see XFS for the default on Ceph soon as well.
Switching to XFS as the default filesystem.
Improved MS Active Directory integration
Container support (is it Docker? seems too early for RHEL to integrate Docker..? maybe it's just LXC?)
systemd is a big win (although a hot topic)
CentOS 7 shouldn't be lagging too far behind. The CentOS team recently got taken up with RHEL, so I think we can expect a CentOS update soon (can't wait!).
Red Hat employs a huge swathe of the systemd developers. It not be surprising at all to see it finally integrated in. If anything, it is surprising it took this long - systemd service files were designed to be significantly easier for service maintainers.
* Docker
* XFS as default filesystem, btrfs available
* systemd and .service files replacing the duct tape of overlapping services and shell scripts
* Normal RHEL stuff like SystemTap support
More info: https://access.redhat.com/site/sites/default/files/pages/att...
The name is identical to a tool I used over a decade ago at SGI. Is this a distant descendant thereof?
Edit: works now
Official press release is so high-level, it even skips the 'mundane' details like that. And the documentation isn't ready yet: https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
I think what is more interesting are the platforms that are not in that list. Internally we build for 32 bit i686, ppc (32 bit) and s390, but AFAIK we don't release those. We also don't build for ARM 32 bit (but aarch64 will be in future[1]).
Of course this is a lot less than Debian, but we have to carefully choose what we are able to support for customers. This is not a throw-it-at-the-wall approach.
[1] http://rwmj.wordpress.com/2014/03/04/red-hat-64-bit-arm-deve...
http://www.redhat.com/about/news/press-archive/2014/1/red-ha...
RedHat's got some convoluted "we can't store source in git" policy going on.
Glad they went with MariaDB, I've had some small problems with certain versions of the mysql jdbc being incompatible with MariaDB due to some kind of protocol quirk, but generally I've been planning as if MySQL development will converge on this project.
