Not Docker. Linux containers (LXC). They predate Docker by a couple years. Docker is app-focused whereas LXC is more machine focused. Docker uses LXC as an underlying technology making them easier to use for deploying apps. Docker is the current poster-child for containers, but most containers are not Docker and containers have existed for years in multiple forms.
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!).
It's LXC. LXC has been around since 2008 (before Docker existed, since Docker builds atop it). And LXC isn't tied to a for-profit company, so RHEL would be more likely to include it.
Was my thoughts exactly. Seems odd to put Docker into a RHEL release, especially since docker only 1.0'ed yesterday. RHEL usually goes for rock solid stable (typically older/matured) packages... LXC seems the natural fit... I could see Docker in RHEL 8 or something...
RHEL can go years without seeing a major version increase. In between now and then, a lot of people are going to want to use containers, including Docker. If RHEL doesn't support them, people are going to use Debian/Ubuntu/CoreOS/etc. instead. So Red Hat is supporting them. They know Ubuntu has a head start on them in the cloud, and they do not want to let them widen that gap.
"Enhanced application development, delivery, portability and isolation through Linux Containers, including Docker, across physical, virtual, and cloud deployments as well as development, test and production environments."
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.
The XFS-as-default change is surprising. Does anyone know what drove this? I don't keep up with XFS development on Linux, so I don't understand why it's a better choice vs. EXT4 for RHEL7 than it might have been for RHEL6.
My understanding is that XFS is now default because it has far better support than ext4 for large (hundreds of TB to PB) volumes. In addition, RedHat employs many core XFS members.
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.
Sure, but these are mostly just arbitrary caps. xfs performance at 50TB is supposed to be better than ext4 at 50TB. I don't know what xfs actually does over ext4, but I do know a little bit about ext4; on-disk it looks very similar to the ancient Unix FFS. xfs may use more scalable on-disk structures.
Looks like XFS supports concurrency better (both on the request side, and on the kernel<->backing store side).
Back in the day, we used xfs instead of ext3 so that when something happened and there was a bad shutdown, our samba servers weren't stuck in fsck for an hour (or a day).
It looks like the enterprise-y features and agreement with partners mostly drove it, but it's unclear. Red Hat doesn't focus on EXT4 bugs but on selling XFS features.
XFS has been stable on Linux for over a decade (since SGI Linux, which was RHEL with XFS, in the early 2000s). btrfs while having some design advantages over XFS and ZFS is still too new for most of Red Hat's customers.
I'm one of those people who had to deal with an XFS corruption about ten years ago, and the recovery process was messy - to say the least. At least with ext4, the recovery is easier to manage.
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.
I had the same experience over 10 years ago - and I was actually at SGI back then.
But that was then. This is now. I'm curious how things have changed meanwhile. I'm going to give this thing a spin.
I also remember the massive performance and effortless delivery of XFS under concurrent access, while using large files. That was fantastic. I would expect that's still the case now.
Of course I'm going to have a bad taste in my mouth for XFS. Because it happened to me. At the time is was particularly frustrating because XFS was claimed to be very stable and should be used over ext3(? I don't remember if ext4 was out yet). Our group ended up moving all of those machines over to ext3/4 and we were quite happy with the results.
I remember when Joyent had their problem, and it made me hedge on ZFS for quite a while as well. Some time working with both Solaris and FreeBSD implementations in production was enough to change my mind.
I'm sure that XFS now-a-days is much more stable - Redhat wouldn't make it the default filesystem if it wasn't. Just because I had a bad experience with it many years ago doesn't mean that I won't use it, but I will evaluate if I need to.
But, I honestly wonder how much longer it will be the default with Btrfs coming along quickly.
XFS was pretty good in the olden days of IRIX - as in twenty years ago when 2Gb SCSI disks were pretty much all you had to work with.
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.
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.
The lifecycle of RHEL is minimum 10 years (longer for some customers). In 10 years time, disks will be considerably larger than what ext4 is comfortable with. I know that ext4 claims to support large disks, but only XFS is actually tested at these levels and known to work properly.
Not only tested and known to work, but tested and known to work for many years now! I first learned of & deployed XFS for volumes of hundreds of TB back in 2009? 2010?
EXT4 cannot be resized while mounted. This is the main reason we use XFS instead of EXT4 where I work, we currently mostly use RHEL 6. This matters a lot for e.g. database masters.
This is surprising to me. I have resized many ext4 partitions while mounted (as / even). You can't shrink them. Yes. But you can grow them. I don't think shrinking partitions is a common operation and IMHO that alone wouldn't warrant a switch of the default file system.
ext4 has some pretty sharp edge cases in terms of performance degradation. For example, readdir() performance is unacceptable in directories that contain lots of dentries (on the order of 100,000s) -- or that ever once did. (Directory read performance was just as bad even with 5 dentries after deleting the rest.) We had to switch to XFS for just that reason.
Actually that is a libc issue. It only reads in 32k of directory entries at a time.
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.
If it were a libc issue, the problem would also occur with XFS. The reason we know it's a filesystem issue is that on ext4, readdir() still takes an eternity even after we delete all the files in the subdirectory.
Yeah, because ext4 never cleans up the dentry table after it's been made. This is a pain.
Unfortunately XFS also sucks for handling larger numbers of files - at the hundreds of millions or larger scale, you're largely metadata bound - and XFS is very slow at this for a number of reasons.
RH did an interesting study a while back [0] on storing 1 billion files, which came out in favor of ext4. If you're able to work around the lack of dentry cleanup, I still think ext4 is probably the best choice here (ideally with the journal on a small SSD) - assuming you can't store them in a database or something more appropriate like mogileFS [1]
Ah, makes sense then. What I've seen (mind you this is mostly Suse), is that by adjusting the sys call buffer size I can get ext4/3 to reach pretty good performance.
Generally though I hate having 1 million + entries in a directory. I'm kind of curious what the use case is for that kind of layout?
In our case we're storing copies of incoming email messages, one per file, into a date-stamped directory. At the beginning of the next day, we add all the previous day's message files into a single .zip file and remove the original files.
I thought there was some ext4 specific mount option you could set to tell it to speed that up significantly? I can't seem to find it now.
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.
Back at the RHEL6 launch (working for Red Hat Support) scuttlebutt around Red Hat was that they weren't confident they had the resources to provide full support for all clients for XFS. At that time it was offered as an add-on for a substantial amount of money. Considering the kind of case work that was being dealt with I don't think this was unreasonable. There was at least 1 time I needed to pull the first few mb of the disk for investigate a corruption issue.
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.
Although you got some pretty good answers there is one point that is not covered: parallel I/O. This is especially important for virtualization hosts as it improves performance significantly.
The precise platforms are: x86_64, ppc64 (big endian) & s390x.
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.
Not so fast - I believe CentOS is planning a 32-bit SIG. I'm sure it won't get near the adoption a Red Hat blessed distribution would get (even considering how 32-bit is on its way out), but it exists.
Anyone have a rough idea of when/if this will effect the Amazon Linux distro for EC2?
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.
Funny, but I didn't know CentOS got acquired by Red Hat. They claim they're keeping a separation between the RHEL team and CentOS team, but CentOS development is basically organized, run and funded by Red Hat now.
It's not really convoluted. Their policy is to only publish SRPMS and tarballs. Really straightforward. The reason behind it (to make Oracle's life harder) is also pretty straightforward, even if you disagree with it.
90 comments
[ 2.3 ms ] story [ 130 ms ] threadhttp://www.redhat.com/about/news/press-archive/2014/1/red-ha...
Edit: works now
* 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?
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!).
http://developerblog.redhat.com/2013/11/26/rhel6-5-ga/
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.
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.
Looks like XFS supports concurrency better (both on the request side, and on the kernel<->backing store side).
This presentation should be interesting to answer your question: http://rhsummit.files.wordpress.com/2014/04/rwheeler_thursda...
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.
I haven't used it since, but I would expect RedHat to have invested in correcting these problems over the years (I hope I'm not expecting too much).
Of course your point about ZFS still stands.
But that was then. This is now. I'm curious how things have changed meanwhile. I'm going to give this thing a spin.
I also remember the massive performance and effortless delivery of XFS under concurrent access, while using large files. That was fantastic. I would expect that's still the case now.
I remember when Joyent had their problem, and it made me hedge on ZFS for quite a while as well. Some time working with both Solaris and FreeBSD implementations in production was enough to change my mind.
I'm sure that XFS now-a-days is much more stable - Redhat wouldn't make it the default filesystem if it wasn't. Just because I had a bad experience with it many years ago doesn't mean that I won't use it, but I will evaluate if I need to.
But, I honestly wonder how much longer it will be the default with Btrfs coming along quickly.
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've always preferred XFS over ext4 on ephemeral cloud instances, because you don't expect it to come back if it crashes.
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.
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.
RH did an interesting study a while back [0] on storing 1 billion files, which came out in favor of ext4. If you're able to work around the lack of dentry cleanup, I still think ext4 is probably the best choice here (ideally with the journal on a small SSD) - assuming you can't store them in a database or something more appropriate like mogileFS [1]
[0]: http://www.redhat.com/summit/2011/presentations/summit/decod...
[1]: https://code.google.com/p/mogilefs/wiki/Start
See also https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
https://www.youtube.com/watch?v=FegjLbCnoBw
Why is that? It doesn't seem to make much sense.
Generally though I hate having 1 million + entries in a directory. I'm kind of curious what the use case is for that kind of layout?
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.
https://news.ycombinator.com/item?id=7872306
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.
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...
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.
RedHat's got some convoluted "we can't store source in git" policy going on.
ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README
https://fedoraproject.org/wiki/EPEL/epel7beta-faq