Red Hat Unveils Red Hat Enterprise Linux 7 | Hacker News Reader

Red Hat Unveils Red Hat Enterprise Linux 7

redhat.com

166 pointsbbzealot86 comments

Open articleView on HN

So:

* 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...

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.

No, explicitly Docker (which includes Linux containers) - see http://www.redhat.com/about/news/press-archive/2014/6/red-ha.... Actually Docker was added post-release to RHEL 6, but it's there out of the box in RHEL 7.

I stand corrected. I read three different release notes on it and all of them mentioned LXC without mentioning Docker.

> Performance Co-Pilot

The name is identical to a tool I used over a decade ago at SGI. Is this a distant descendant thereof?

Most likely, does the tool you remember look similar to http://www.performancecopilot.org/ ?

Yup, same one. Cool.

Yes it is.

Several ex-SGI developers are now employed by Red Hat.

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.

edit: cleanup wording.

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.

The new release increases ext4 from 16TB to 50TB and xfs from 100TB to 500TB.

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.

This presentation should be interesting to answer your question: http://rhsummit.files.wordpress.com/2014/04/rwheeler_thursda...

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.

10 years ago XFS on Linux was nowhere near as reliable as XFS on IRIX, plus it was missing tools that were available in IRIX.

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.

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.

Eight years ago Joyent suffered high-profile, irretrievable data corruption with ZFS. By your own metric I'm surprised you're using that.

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.

XFS-on-Linux worked fine until you had a kernel panic or power outage, and would always shit the bed on reboot.

I've always preferred XFS over ext4 on ephemeral cloud instances, because you don't expect it to come back if it crashes.

-Disclaimer: A Guess-

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?

We used XFS at a VFX studio, circa '97.

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.

ext4 can be resized while mounted (using resize2fs). It can only be extended, not shrunk however.

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.

Unless it's been changed in the past couple of years, XFS can't be shrunk at all.

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]

[0]: http://www.redhat.com/summit/2011/presentations/summit/decod...

[1]: https://code.google.com/p/mogilefs/wiki/Start

Slide 32 suggests that XFS performance took the lead again after RHEL 6.2. Am I mistaken?

I wonder if you know about Dave Chinner's talk, which addresses the metadata performance issue. (they fixed it)

https://www.youtube.com/watch?v=FegjLbCnoBw

I hadn't seen that - that's interesting. Thanks.

> Yeah, because ext4 never cleans up the dentry table after it's been made.

Why is that? It doesn't seem to make much sense.

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.

dir_index. Funny this is being concurrently discussed on the "Tell HN: The site was offline. What changed?" thread.

https://news.ycombinator.com/item?id=7872306

dir_index is on by default for ext4 filesystems. It doesn't help in this case.

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.

This is looking to be an impressive release.

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!).

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.

Actually it's Docker :)

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...

We have been working with redhat for months. They're amazingly active maintainers of Docker.

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.

Docker was added to RHEL 6. Red Hat can move faster than you think. :-)

http://developerblog.redhat.com/2013/11/26/rhel6-5-ga/

Wow. I stand even more corrected. Additionally, it's pretty cool that they pushed it into RHEL 6 given the slow upgrade paths of folks that use RHEL.

"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."

I stand corrected. I read three different release notes on it and all of them mentioned LXC without mentioning Docker.

> systemd is a big win (although a hot topic)

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.

Especially since systemd and its prerequisites were very much designed around Red Hat's needs and design from the start.

So you're basically saying enterprise linux?

You can follow along here: http://seven.centos.org/

It's docker.

Yes, it's Docker. See the release notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_E...

Which platforms does it run on?

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...

x86_64 and PPC afaik

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.

[1] http://rwmj.wordpress.com/2014/03/04/red-hat-64-bit-arm-deve...

AFAIK the main reason we still build the 32-bit stuff is to ship multilib packages for their 64-bit siblings.

Thanks for not realeasing the 32bit arch, makes package building and management considerably easier!

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.

Great! I can't wait for CentOS. Well, I have to. :-)

Thanks for the recent cooperation between Red Hat and CentOS, we may not have to wait much!

http://www.redhat.com/about/news/press-archive/2014/1/red-ha...

I'm right there with you. Started with RHEL but have since moved to CentOS, even for pet projects or cloud servers I spin up.

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.

Looks like EPEL for RHEL7 is progressing.

https://fedoraproject.org/wiki/EPEL/epel7beta-faq

Anyone taken a look at how to get sources for this?

RedHat's got some convoluted "we can't store source in git" policy going on.

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.

Sure, but they're not even publishing SRPMS any more.

It seems that all source code will be published through CentOS's repositories:

ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README

I heard that the only way to safely run docker is to have it secured by SELinux, which is available in RHEL and Core OS.

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.

Does anyone here know which graph driver Docker is using in RHEL7 (aufs or devmapper)?

Devmapper (thin lvm/dm-thin) AFAIK, AuFS is not supported by RHEL at all.

404

Edit: works now

Looks like they took it down then fixed it again.

Got the same 404 and after refresh it works. Maybe its overloaded or buggy

I still get the:

  404 Error

Reply on news.ycombinator.com