Domain: redhat.com
Stories and comments across the archive that link to redhat.com.
Comments · 4,506
-
Re:This was even a question?
So, let me rephrase, for mission critical stuff, you install stuff marked as "technology preview" ?
( cf https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/ar01s03.html ).You know, the whole TP that is explicitely written as "not to be used in production" from the same documentation :
https://access.redhat.com/support/offerings/techpreview/So in the end, the vendor say in the release note "do not do this, this may break", and when it break, you just rant because you forgot that part ?
-
Re:sorry, don't trust redhat
Red Hat is the sole, most significant contributor or one of the main contributors to to an awful lot of those 'other open source projects':
https://fedoraproject.org/wiki/Red_Hat_contributions (and that's massively incomplete)
It's a core principle of RH work that as much work as possible is done or pushed upstream, and that RH products should be 100% F/OSS (the exception to this is when we acquire proprietary software and spend a couple of years doing the legal and engineering spadework to make it 100% F/OSS, which is just a terrible thing for us to do, I know).
All of the source for RHEL is publicly available - http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ (and other paths on that server), go knock yourself out. (This is not minimal legal compliance, BTW; minimal legal compliance would be providing only copyleft sources, and providing them only to customers. We don't have to put the entire SRPM set up for public download on our own servers). You can get an evaluation version of RHEL 6 for free at https://ca.redhat.com/products/enterprise-linux/server/download.html - where 'evaluation' just means 'you only get updates for X days'. You can buy the RHEL Developer Suite - https://www.redhat.com/apps/store/developers/rhel_developer_suite.html - which includes RHEL with every single add-on, and access to all updates, just like having a commercial support contract only without the commercial support - for a measly $99. Or you can just go download CentOS or Scientific Linux, which projects RH does nothing whatsoever to impede.
RH is the single leading contributor to upstream OpenStack: http://readwrite.com/2013/04/16/will-red-hats-openstack-contributions-turn-to-gold
Name me a company that manages to run a sustainable business while contributing more to F/OSS development. One company.
-
Re:sorry, don't trust redhat
Red Hat is the sole, most significant contributor or one of the main contributors to to an awful lot of those 'other open source projects':
https://fedoraproject.org/wiki/Red_Hat_contributions (and that's massively incomplete)
It's a core principle of RH work that as much work as possible is done or pushed upstream, and that RH products should be 100% F/OSS (the exception to this is when we acquire proprietary software and spend a couple of years doing the legal and engineering spadework to make it 100% F/OSS, which is just a terrible thing for us to do, I know).
All of the source for RHEL is publicly available - http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ (and other paths on that server), go knock yourself out. (This is not minimal legal compliance, BTW; minimal legal compliance would be providing only copyleft sources, and providing them only to customers. We don't have to put the entire SRPM set up for public download on our own servers). You can get an evaluation version of RHEL 6 for free at https://ca.redhat.com/products/enterprise-linux/server/download.html - where 'evaluation' just means 'you only get updates for X days'. You can buy the RHEL Developer Suite - https://www.redhat.com/apps/store/developers/rhel_developer_suite.html - which includes RHEL with every single add-on, and access to all updates, just like having a commercial support contract only without the commercial support - for a measly $99. Or you can just go download CentOS or Scientific Linux, which projects RH does nothing whatsoever to impede.
RH is the single leading contributor to upstream OpenStack: http://readwrite.com/2013/04/16/will-red-hats-openstack-contributions-turn-to-gold
Name me a company that manages to run a sustainable business while contributing more to F/OSS development. One company.
-
Re:sorry, don't trust redhat
Red Hat is the sole, most significant contributor or one of the main contributors to to an awful lot of those 'other open source projects':
https://fedoraproject.org/wiki/Red_Hat_contributions (and that's massively incomplete)
It's a core principle of RH work that as much work as possible is done or pushed upstream, and that RH products should be 100% F/OSS (the exception to this is when we acquire proprietary software and spend a couple of years doing the legal and engineering spadework to make it 100% F/OSS, which is just a terrible thing for us to do, I know).
All of the source for RHEL is publicly available - http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ (and other paths on that server), go knock yourself out. (This is not minimal legal compliance, BTW; minimal legal compliance would be providing only copyleft sources, and providing them only to customers. We don't have to put the entire SRPM set up for public download on our own servers). You can get an evaluation version of RHEL 6 for free at https://ca.redhat.com/products/enterprise-linux/server/download.html - where 'evaluation' just means 'you only get updates for X days'. You can buy the RHEL Developer Suite - https://www.redhat.com/apps/store/developers/rhel_developer_suite.html - which includes RHEL with every single add-on, and access to all updates, just like having a commercial support contract only without the commercial support - for a measly $99. Or you can just go download CentOS or Scientific Linux, which projects RH does nothing whatsoever to impede.
RH is the single leading contributor to upstream OpenStack: http://readwrite.com/2013/04/16/will-red-hats-openstack-contributions-turn-to-gold
Name me a company that manages to run a sustainable business while contributing more to F/OSS development. One company.
-
Fedora just plain sucks
First it was SystemD, which is horrible and unnecessarily complex and obtuse. Whatever genius came up with it I'd like to thank personally with a punch to the face. Then the geniuses decided to go for the gold and piss thousands of people off by bricking everyone on upgrade without warning: https://bugzilla.redhat.com/show_bug.cgi?id=737508
-
Re:It's about liability and responsibility of faul
-
Re:Set up VLANs
I would recommend using OpenStack and RDO if you can tie together the physical machines into a "cloud" like system (vs. say just running a single hypervisor software per computer like virtualbox).
Each student could be allocated their own project/tenant with appropriate quotas and limits. If setup with a VLAN type system, it is possible to isolate entire networks of VMs for a given project (allowing more than a single VM per student if the hardware can support it) and you can provide some basic images of where you want the students to start from.
http://openstack.redhat.com/Main_Page
I know it sounds like a bit of overkill, but it provides a lot of functionality that you can control from a more centralized location without the need of setting up VBox on every host.
The students can interact with the hosts (depending on how you do it) via the network directly or via the dashboard (vnc-like) web page.
-
Re:Well I might try Flash free browsing again..
it has been able to play h.264 since firefox 14. just build it with --enable-gstreamer. (this is easy to do if you run gentoo. most major distros have a bug open asking them to enable the gstreamer support. eg https://bugzilla.redhat.com/show_bug.cgi?id=843583 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917 )
--
my name is ssam and i have been flash free for 5 months -
You don't understand the problem
The problem with "XFS" eating data wasn't with XFS - it was with the Linux devmapper ignoring filesystem barrier requests.
Gotta love this code:
Martin Steigerwald wrote:
> Hello!
>
> Are write barriers over device mapper supported or not?Nope.
see dm_request():
/*
* There is no use in forwarding any barrier request since we can't
* guarantee it is (or can be) handled by the targets correctly.
*/
if (unlikely(bio_barrier(bio))) {
bio_endio(bio, -EOPNOTSUPP);
return 0;
}Who's the clown who thought THAT was acceptable? WHAT. THE. FUCK?!?!?!
And it wasn't just devmapper that had such a childish attitude towards file system barriers:
Andrew Morton's response tells a lot about why this default is set the way it is:
Last time this came up lots of workloads slowed down by 30% so I dropped the patches in horror. I just don't think we can quietly go and slow everyone's machines down by this much...
There are no happy solutions here, and I'm inclined to let this dog remain asleep and continue to leave it up to distributors to decide what their default should be.
So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between.
It turns out that the "getting away with it" factor is not just luck. Ted Ts'o explains what's going on: the journal on ext3/ext4 filesystems is normally contiguous on the physical media. The filesystem code tries to create it that way, and, since the journal is normally created at the same time as the filesystem itself, contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.
I love that italicized part. "OMG! Data integrity causes a performance hit! Screw data integerity! We won't be able to brag that we're faster than Solaris!"
See also http://www.redhat.com/archives/rhl-devel-list/2008-June/msg00560.html
There's a lot more out there if you care to look.
Toss in other things like the way Linux handles NFSv2 group membership (More than 16? Let's just silently drop some!) and lots of fanbois wonder why I view Linux as little better than Windows. Hell, Microsoft may fuck things up six ways from Sunday, but they're not CHILDISH when it comes to things like data integrity.
-
Re:Installer a little better than F18's
That's actually only partially true. Fedora 18 didn't include MATE as an option while doing a DVD install, but if you changed the package location in Anaconda to "closest mirror", you would suddenly get a much larger set of available desktops, including Cinnamon, MATE and others. The reason for this should be obvious: there's only so much space on a DVD, so we tend to keep the set of packages on it limited to the most popular set. Which at the time of Fedora 18's release did *not* include Cinnamon or MATE.
We're definitely accepting criticism for how we can clean up the interface and make important options more visible. That's very nearly the whole point of the Alpha release. Please file bugs at http://bugzilla.redhat.com/ against the "anaconda" component of the Fedora project.
-
Re:Good luck with that code name
It doesn't matter if things do break, we'll never find out thanks to this
;-) -
Re:"Doing something no other distro vendor has don
Red Hat is doing something no other distro vendor has done
... Gentoo? And Daniel Robbins' Funtoo project?
These two distros are very similar, with a few key differences but in both you can choose how stable or not stable you would like. If you want stable, you can have stable. If you need bleeding edge, you can have bleeding edge.
Granted its not "automatic updates" but I don't like the idea of my server doing updates like that without me initiating them.
The point is that RDO isn't a new distro, or a specific RH flavour of OpenStack, but just plain vanilla OpenStack builds, nicely packed in RPM's and with a "yum" repository. So RH based distros like Fedora 18, CentOS, Scientific Linux can install and maintain it, just by enabling the RDO yum repo.
There is a quickstart guide and lots of documentation here:
http://openstack.redhat.com/QuickstartAll in all, this makes it really easy to test and play around with OpenStack.
-
Re:If they have to struggle...
How far back does RedHat actively support, or any Linux provider for that matter. I sincerely doubt anyone is providing free commercial support for decade old versions of their OS.
Wrong.
See https://access.redhat.com/support/policy/updates/errata/ and note that:
"Red Hat Enterprise Linux 5 and 6 are offered with 10 years of Production Phase support, followed by a three year Extended Life Phase."
Then add to this the fact the the free CentOS and its ilk mirror Red Hat's support timing. Then you have 13 years of free support. -
Re:Yet more fragmentation
Maybe in compilers, kernel, or server software ? You know, all of those stuff that are used everywhere but working almost so well that no one care about them, listed on http://community.redhat.com/
take kvm for example, you likely depend on it dues to the use of vm and cloud, but you do not link the VM that host some blog to RH money, that paid kvm developpers. You send a email, but you do not think "maybe that's because people have been working on the kernel networking side, paid by a company". You do not think "maybe my bank is using RHEL and some security problem were prevented due to selinux or general hardening thanks to stuff paid by RH".
And the same goes to lots of others company too, Intel, IBM, Suse, etc. That's where the money goes. Or to sponsoring of Linux Foundation, Gnome foundation, Openstack, eclipse, etc. Or maybe to lawyers ( see rackspace vs some patent troll, see OIN ).
-
Re:Article is garbage
There is a rate limiting patch for BIND. The BIND package in RHEL/CentOS has it now:
https://bugzilla.redhat.com/show_bug.cgi?id=873624A person has also attached a graph showing its effect on that bug page. I know of some other places which are using this patch.
(Disclaimer: I work for the organization that produces BIND.)
-
Uniloc v Rackspace
Oh Noes! The Hon. Leonard Davis tossed this case out of his court!
Troll: zero. FOSS: 1
Comments?
Try to disgorge a reasonable answer. Please avoid responses along the lines of
This was an example of a patent that should never have been granted. IV only sues based on the right kind of patent.
-
Security...
A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?
The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.
First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.
Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.
Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.
Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.
If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.
[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]
-
Re:This is why people hate MS
Does Red Hat or Apple support a 10 year old OS? Do any open distros do this?
RHEL has a 13 year support window. https://access.redhat.com/support/policy/updates/errata/
-
Re:This may not be so bad...
Geforce FX, 6000 series and 7000 integrated chipsets draw all kinds of multicolored garbage in GTK3 DEs with open drivers and, with closed drivers, they draw garbage and either hang or are unusably slow (not being hyperbolic - I mean actually taking minutes to draw a window). Nvidia aknowledged the issue, but stated it's not their problem. Support for legacy is only for Xorg ABI changes. Nouveau, on the other hand, is understaffed, receives no official help from them and has been going through a rewrite, so no progress has been made there either. In fact, things have gotten worse. Look at this bug's report date:
-
Re:Why would you need a web browser on a server?
Pease link me to Debian's APL cert, or at least a press release (like this). Then I can talk to my boss about using your tax money to pay me to install an OS that does, err, what RHEL already does.
-
Re:What Components?
RHEL has been using yum since version 5. And up2date is GPL, at least if this is the source: ftp://ftp.redhat.com/redhat/linux/enterprise/4/en/os/x86_64/SRPMS/up2date-4.4.5-1.src.rpm
-
Re:Why would you need a web browser on a server?
It's actually 10 years; 13 if you pay extra.
https://access.redhat.com/support/policy/updates/errata/ -
Re:RHEL is for servers not desktops
Frankly it annoys me that there are no desktop distros that are maintained for longer than a year or two
Allow me to rid you of your annoyance:
https://www.redhat.com/products/enterprise-linux/desktop/ -
Re:Microsoft and Open Source don't mix
If they contributed solely out of their own business interests, and their contributions add nothing of value other than compatibility with Microsoft's proprietary software, and nobody who doesn't want to use Microsoft's proprietary software will see any benefit whatsoever from any of the changes Microsoft contributed to the kernel, then yeah, I would say it's fair to rate Microsoft's contributions to the Linux kernel lower than those of a company like, say, Red Hat.
Speaking of Red Hat it looks like the guest support for Hyper-V is a fairly big feature in Red Hat Enterprise Linux 5.9. I'm just speculating here, but it is likely that Microsoft's contribution adds business value to companies like Red Hat and eventually to their customers. So I don't get what is so bad with Microsoft contributing to open source.
-
Re: forgot RH7
This is the Linux community. I'm surprised that a more standard-compliant compiler is a "bad thing" now.
I'm no expert, but the site http://www.redhat.com/advice/speaks_gcc.html is listening the bugs in the broken gcc and is listening them after the language: C, C++ and Assembler.
You would think that the open source and Linux community would rather have a much stricter compiler then to rely solely on a specific branch of gcc.
-
Re:Alan Cox rants on G+! Film at 11!
I think the grub2 password protect thing is fixable - need to add --unrestricted to allow anyone to boot the entry, so it doesn't ask for a password every time. There is a bug for it with the details. Granted it should just work, but it's being tracked and should see the light of day someday... I gather from the trail of comments it is not as trivial as would be liked to fix.
https://bugzilla.redhat.com/show_bug.cgi?id=840204 https://bugzilla.redhat.com/show_bug.cgi?id=853430
On the updated packages, use cobbler (or whatever) to create a kickstart that adds the updates repo - during the install the latest version should get installed, unless there is some reason that now doesn't work now, but I can't imagine why.
I do use kickstarts to do automated installs and they do work. Without more detail I can't help you more, except to say that I know some of the kickstart options, especially around disk configuration, have changed.
Why doesn't GDM run? Do you just need to run a post install script to ln -sf to set
/etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target? Would need more details to even say why it won't work..."I'm not the guy you responded to, but can I get a nice gift?
-
Re:Alan Cox rants on G+! Film at 11!
I think the grub2 password protect thing is fixable - need to add --unrestricted to allow anyone to boot the entry, so it doesn't ask for a password every time. There is a bug for it with the details. Granted it should just work, but it's being tracked and should see the light of day someday... I gather from the trail of comments it is not as trivial as would be liked to fix.
https://bugzilla.redhat.com/show_bug.cgi?id=840204 https://bugzilla.redhat.com/show_bug.cgi?id=853430
On the updated packages, use cobbler (or whatever) to create a kickstart that adds the updates repo - during the install the latest version should get installed, unless there is some reason that now doesn't work now, but I can't imagine why.
I do use kickstarts to do automated installs and they do work. Without more detail I can't help you more, except to say that I know some of the kickstart options, especially around disk configuration, have changed.
Why doesn't GDM run? Do you just need to run a post install script to ln -sf to set
/etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target? Would need more details to even say why it won't work..."I'm not the guy you responded to, but can I get a nice gift?
-
Re: forgot RH7
Maybe you are wrong: http://www.redhat.com/advice/speaks_gcc.html
He's right about ugly incompatibilities. Old code which complied fine and compiled on other platforms didn't work on RH7. That the underlying reason was non-standards compliant programming and a much stricter compiler didn't change the problem. It also didn't help that the compiler was enforcing c++ standards against c code.
-
Re: forgot RH7
Maybe you are wrong: http://www.redhat.com/advice/speaks_gcc.html
The flamewar is strong with these ones.
-
Re: forgot RH7
Maybe you are wrong: http://www.redhat.com/advice/speaks_gcc.html
-
Re:What am I missing?
CentOS not a fork. It is a recompilation (and minor change) of RHEL. RHEL 5 & 6 are both releasing updates https://access.redhat.com/support/policy/updates/errata/. They will continue to do so for 10 years after their original release.
I believe a fork seeks to update and maintain code independant of the original (OpenOffice.org forked as LibreOffice). CentOS does not do this long-term, and for each RHEL release they re-base their distribution.
-
Re:What am I missing?
RHEL 5.x has not reached its EOL.
-
Re:It's GNU/Linux
It's GNU/Linux, not GUN/Linux.
Depends on who you bought it from. If you bought it from Red Hat, its GNU/Linux. If you bought it from Red Jacket, it's Gun/Linux.
-
Re:I feel like Fedora 18 is a bust
I've been watching and trying right along. The last time I tried was with TC 3. I still couldn't make heads or tails of the partitioning GUI, and it still seemed like it was going to erase everything instead of installing into a new partition.
Admittedly, I've been trying this on a VM which I've used btrfs for everything. So it doesn't test LVM. Maybe that works now. Unfortunately, all the systems I use LVM for are (for me) mission critical. Though I don't suppose there's any harm in firing up the installer and trying.
-
Re:There is a fix
What other manufacturer provides quick fixes for a decade old OS that is now three versions out of date? Red Hat and CentOS https://access.redhat.com/support/policy/updates/errata/ http://wiki.centos.org/
-
Assigned CVE-2012-6084 for this issue
As per http://www.openwall.com/lists/oss-security/2013/01/01/3 this issue was assigned CVE-2012-6084. Remember folks, you can get your CVEs in advance which makes life easier for everyone. Please see http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for details.
-
Re:Passwords are a worse vulnerability
And no, last time I checked openssh could not do that
Last I checked, PasswordAuthentication is allowed inside a Match block, so
PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8PasswordAuthentication yes
With a note that it doesn't always work:
https://bugzilla.redhat.com/show_bug.cgi?id=869903 -
Re:Pay the $3.99
"For instance Red Hat exclusively gives source to paid enterprise customers"
This is not at all true.
Here, have all the SRPMs you like, on me:
http://ftp.redhat.com/pub/redhat/linux/enterprise/
We *could* only give source to paid enterprise customers, if we chose, but we choose to host it for anyone to download. You can actually get RHEL binaries free too, you have to sign up for an 'evaluation' though. We only make official update binaries available to paid enterprise customers, via the RH update network.
-
Re:An easy solution!
-
Re:Gaining traction should be easy
So you didn't know that Redhat offers support for the desktop? I assumed you were talking about home users since you said there is just no option for somebody, and there is certainly enterprise level support for the desktop. Just accept that you made a ridiculous unfounded claim, which I countered in 1 Google search, and move on with your uninformed life.
-
Re:Fuck secure boot.
I find it disappointing that instead of actively fighting secure boot and making a BIG PUBLIC STINK about it and embarrassing everyone involved in implementing this, the community is aquiescing to the concept and "working with it."
The community is not united against secure boot. There are real benefits for the user.
One security threat that has been getting a lot of interest lately is the ability to ensure the integrity of the early boot sequence - the handoff of control from the lowest level system firmware (traditionally provided by the hardware vendor) through to the operating system kernel. This is important because there have increasingly been real-world exploits where fraudulently modified early boot code has introduced vulnerabilities into the operating system.
To confront this challenge, the upcoming generation of system firmware, referred to as Unified Extensible Firmware Interface (UEFI) secure boot, has capabilities in the system startup sequence designed to only pass control to operating system software that can be confirmed to be not tampered with. The mechanism used to confirm the integrity of operating system software is not novel, rather it uses traditional key signing and variations of checksumming. While these mechanisms have traditionally been used higher up in the software stack and later in the startup sequence - what is new is the fact that these validation checks are expected to now be available at the earliest points in the system startup sequence. Performing the checks early is crucial as it provides a safe, verified starting point.
UEFI Secure Boot [Tim Burke, vice president, Linux Engineering, Red Hat]
-
Re:NFS + ZFS
I don't see any indication that a) this has any relation to the size of the directory
The cited bug points out a problem with readdir(). This manifests itself as failures with other software, including dovecot (where maildir is used) and bonnie++. Some of those other bugs were reported and marked as duplicates, some weren't.
Ultimately it boiled down to a flaw in Linux NFS that was fixed by Trond Myklebust and was still perculating through distributions over a year later.
Never in years has it given me one problem, but hey, that's just me.
Yeah, that's just you. Me? I've been watching hapless administrators discover NFS flaws since the 90's and I have long since abandoned NFS as a serious tool for production operations. It's fine in most cases as a file share for interactive use (/home and ad hoc shares) and not much else. Under certain conditions with extremely good NFS implementations (netapp, for example) you can pull it off. The other 99% of the time it's just a mistake.
-
Re:NFS + ZFS
I don't see any indication that a) this has any relation to the size of the directory
The cited bug points out a problem with readdir(). This manifests itself as failures with other software, including dovecot (where maildir is used) and bonnie++. Some of those other bugs were reported and marked as duplicates, some weren't.
Ultimately it boiled down to a flaw in Linux NFS that was fixed by Trond Myklebust and was still perculating through distributions over a year later.
Never in years has it given me one problem, but hey, that's just me.
Yeah, that's just you. Me? I've been watching hapless administrators discover NFS flaws since the 90's and I have long since abandoned NFS as a serious tool for production operations. It's fine in most cases as a file share for interactive use (/home and ad hoc shares) and not much else. Under certain conditions with extremely good NFS implementations (netapp, for example) you can pull it off. The other 99% of the time it's just a mistake.
-
Re:NFS + ZFS
I don't see any indication that a) this has any relation to the size of the directory
The cited bug points out a problem with readdir(). This manifests itself as failures with other software, including dovecot (where maildir is used) and bonnie++. Some of those other bugs were reported and marked as duplicates, some weren't.
Ultimately it boiled down to a flaw in Linux NFS that was fixed by Trond Myklebust and was still perculating through distributions over a year later.
Never in years has it given me one problem, but hey, that's just me.
Yeah, that's just you. Me? I've been watching hapless administrators discover NFS flaws since the 90's and I have long since abandoned NFS as a serious tool for production operations. It's fine in most cases as a file share for interactive use (/home and ad hoc shares) and not much else. Under certain conditions with extremely good NFS implementations (netapp, for example) you can pull it off. The other 99% of the time it's just a mistake.
-
Re:XFS
The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.
ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.
Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.
I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.
It didn't help that Linux didn't address the DM device bug where write barriers were basically ignored until a couple years ago.
-
Re:XFS
The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.
ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.
Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.
I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.
-
Re:NFS + ZFS
As recently as Redhat/CentOS 6.2 the NFS kernel client choked on large NFS directories (11 months ago,) breaking Maildir among other things. NFS, particularly on Linux, has always been a flaky POS. Please stop inflicting NFS on people. NFS is for
/home and not much else.Yeah, I know there aren't any good alternatives. That doesn't mean using NFS isn't a mistake.
-
Re:This is a good thing
End of production, not end of life.
-
Re:This isn't devs listening
This is just another account of how amazingly full of shit the GNOME team (Red Hat, let's just call it with it real name) continues to be.
I agree with you 100% on this. Have a look at some of the recent interactions with the Fedora (aka RedHat) team and them shoving Gnome 3 down peoples throats:
https://bugzilla.redhat.com/show_bug.cgi?id=865922
continues here:
https://bugzilla.redhat.com/show_bug.cgi?id=875433Translation of it: Screw the End User, you'll do it OUR WAY.
-
Re:This isn't devs listening
This is just another account of how amazingly full of shit the GNOME team (Red Hat, let's just call it with it real name) continues to be.
I agree with you 100% on this. Have a look at some of the recent interactions with the Fedora (aka RedHat) team and them shoving Gnome 3 down peoples throats:
https://bugzilla.redhat.com/show_bug.cgi?id=865922
continues here:
https://bugzilla.redhat.com/show_bug.cgi?id=875433Translation of it: Screw the End User, you'll do it OUR WAY.