Announcement

Collapse
No announcement yet.

Red Hat Announces General Availability Of Red Hat Enterprise Linux 7

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Luke View Post
    Curious about why they went with XFS and not ext4. Did one of last year's ext4 data loss bugs have a corner case that escaped the bugfixes? Is XFS faster or more easily recovererd than ext4?
    See this article: http://www.internetnews.com/ent-news...ilesystem.html
    This website also made a tour with beta version: http://www.phoronix.com/scan.php?pag...l7_beta1&num=1

    Comment


    • #12
      Originally posted by kpedersen View Post
      It doesn't look that great. Just look at the minimize / maximize and close buttons. They look childish, round and old fashioned like how sci-fi used to look in the 80s.
      The buttons look fine, not sure what you are baying at the moon about. The only thing I am not really sold on is the way the workspace switcher is handled, but to be fair that is what the Activities overview is supposed to be for anyway. GNOME Classic actually turned out much better than some expected.

      Comment


      • #13
        Originally posted by funtastic View Post
        I've read that XFS is a better filesystem, and ext4 is getting obsolete and has some design flaws. The problem with XFS was until a while ago the implementation was not that good, but that has been fixed.
        Scalability is a major concern for RHEL. In RHEL 7 the maximum size for an ext4 filesystem is 50TB; for xfs it's 500TB.

        ext4 is a fully-supported option for RHEL 7 (as xfs was for RHEL 6), the change is simply a flip of the *default* from ext to xfs.

        Is there a best anything? Perhaps. I, personally, tend to think that home-made chocolate chip cookies are the best dessert. However, when it comes to file systems... there are no absolutes.File systems come in all shapes and sizes; and where one may be perfect for a particular application or scenario – it may not be right for other use cases. This is where Red Hat Enterprise Linux 7 beta shines as it brings a variety of substantial enhancements to file systems in the form of scalability improvements, performance enhancements, and file system choices.The big file system news in Red Hat Enterprise Linux 7 beta is that XFS will be the default file system for the boot, root, and user data partitions. Naturally, the existing ext4 file system (the default in Red Hat Enterprise Linux 6) will be fully supported, along with the earlier ext variants (ext2 and ext3). In fact, should you choose to stay with ext4, there is no requirement to leave - it will be an available option during the Red Hat Enterprise Linux 7 beta software installation.Up above I had mentioned scalability improvements... in short, Red Hat Enterprise Linux 7 beta increases the maximum file system size limits for both XFS and ext4. For XFS, the maximum file system size limit increases from 100TB to 500TB while for ext4 it increases from 16TB to 50TB. For many workloads the file system choice will not have measurable impact on application performance but XFS will likely perform better than ext4, particularly in large scale configurations.Expanding on performance, in case you haven’t heard of it, there is a new caching file system in Red Hat Enterprise Linux called FS-Cache. Initially delivered as Tech Preview in Red Hat Enterprise Linux 6, FS-Cache is a fully supported feature in the Red Hat Enterprise Linux 7 beta. It provides a persistent local cache that can be used by file systems to take data retrieved over the network and cache it on a local disk. This helps minimize network traffic for users accessing data from a file system mounted over the network (for example, NFS). FS-Cache can significantly reduce the network and server loading by satisfying read requests locally without consuming network bandwidth.Finally, with respect to additional file system choices, Red Hat Enterprise Linux 7 beta allows for the use of Btrfs. Btrfs is a relatively young file system that has integrated basic volume management, snapshot support, and full data (and metadata) integrity checksumming. A guiding design criteria for Btrfs was a unified, easy to use, command line interface to drive advanced features. Without any additional hardware or external software, Btrfs is able to combine multiple drives into basic RAID sets and allows users to perform snapshots. It is a file system which emphasizes an ease of use that is well suited for non-enterprise, commodity hardware.Note that file systems like Btrfs are included in the beta of Red Hat Enterprise Linux 7 because we know how critical new features like this are to our customers. While additional testing of Btrfs is required to ensure its readiness for production Red Hat Enterprise Linux environments, your feedback at this stage is important. With this in mind, for those with existing subscriptions, we encourage you to download the beta software and to let us know what you think!Also, keep your eyes peeled for more information (from me) on file system enhancements in the Red Hat Enterprise Linux 7 beta. I plan to review how NFS updates can increase network performance and how a number of significant enhancements to the GFS2 shared disk file system can help boost overall system performance.

        Comment


        • #14
          Originally posted by Luke View Post
          I heard that every sold copy of RHEL comes with on-call tech support(that's what's actually being paid for),
          Nope, you can buy subscriptions without support, so that you only get access to software/updates.

          Comment


          • #15
            Originally posted by funtastic View Post
            I've read that XFS is a better filesystem, and ext4 is getting obsolete and has some design flaws. The problem with XFS was until a while ago the implementation was not that good, but that has been fixed.
            Some of our systems use XFS on RHEL6, solely because EXT4 on RHEL6 is limited to 16TB, and it has a marked tendency to truncate files to zero bytes when there's a power failure. So I'm surprised by this decision, too.

            Normally we have redundant power, so it only happens on our test machine with a single supply, but it seems far less reliable than Ext4 (which, AFAIR, also used to truncate files on power failure until someone beat some sense into the developers).

            Comment


            • #16
              Originally posted by movieman View Post
              Some of our systems use XFS on RHEL6, solely because EXT4 on RHEL6 is limited to 16TB, and it has a marked tendency to truncate files to zero bytes when there's a power failure. So I'm surprised by this decision, too.

              Normally we have redundant power, so it only happens on our test machine with a single supply, but it seems far less reliable than Ext4 (which, AFAIR, also used to truncate files on power failure until someone beat some sense into the developers).
              You need space > 16TB? What do you run, movie streaming site or something?

              Comment


              • #17
                Originally posted by MartinN View Post
                You need space > 16TB? What do you run, movie streaming site or something?
                Enterprise
                It's unlikely it's on his home desktop. I've worked with filesystems far over 100TB at work.

                Comment


                • #18
                  I always thought support was the POINT to RHEL

                  Originally posted by Vim_User View Post
                  Nope, you can buy subscriptions without support, so that you only get access to software/updates.
                  I always figured the only reason anyone would pay for a Linux distro when others are free was to get the support. After all, a corporation would otherwise be hiring someone on salary to do the same job anyway, possibly at greater cost. How many bare subscriptions w/o support contracts does Red Hat sell?

                  Comment


                  • #19
                    Originally posted by Luke View Post
                    I always figured the only reason anyone would pay for a Linux distro when others are free was to get the support. After all, a corporation would otherwise be hiring someone on salary to do the same job anyway, possibly at greater cost. How many bare subscriptions w/o support contracts does Red Hat sell?
                    A considerable number. Academic institutions do this because they like getting the software from a large vendor even if they don't really need the support services from Red Hat directly. Some institutions need support from certified software vendors but not for the base platform. Some long term evaluations are done on such subscriptions. Others just want to provide back to Red Hat. Yet more need to do it for regulatory compliance etc.

                    Comment


                    • #20
                      16TB really not that big anymore

                      Originally posted by MartinN View Post
                      You need space > 16TB? What do you run, movie streaming site or something?
                      I've got 6TB in a 3 disk raid0 in the video editing machine I am using right now. Yes, backups are kept current as there are two of these machines.

                      My 4-disk HDD drawer assembly in the best machine can hold 4 of the 4TB drives now available at Micro Center for $160 each, which would be 16TB. Seagate has 6TB enterprise drives, 4 of those in JBOD or RAID 0 is 24 TB, you get 18TB with 4 of those in RAID 5. The only advantage I see to RAID 5 is if you get fewer whole-filesystem failures you don't have to restore a huge filesystem from backup as often (yes, I've done it more than once).

                      There are server cases that can accomodate huge numbers of drives, often used where fast access is required. BTW, if I edited long form movies in 4K my file system would not be big enough! A 30 sec 4K clip in the same format would be 4x the size of my 1080p camera's clips, now figure you might be shooting in a less compressed format on top of that. Figure an hour's shoot making not 8GB of clips, but 32 GB if the camera used H264, maybe 10x that or more if uncompressed. Now figure hundreds of hours of shooting for just one movie, to boil down to a 2-3 hour final cut.

                      Comment

                      Working...
                      X