Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday May 26 2015, @04:16PM   Printer-friendly
from the patch-immediately dept.

The combination of RAID0 redundancy, an ext4 filesystem, a Linux 4.x kernel, and either Debian Linux or Arch Linux has been associated with data corruption.

El Reg reports EXT4 filesystem can EAT ALL YOUR DATA

Fixes are available, one explained by Lukas Czerner on the Linux Kernel Mailing List. That post suggests the bug is long-standing, possibly as far back as the 3.12-stable kernel. Others suggest the bug has only manifested in Linux 4.x.

[...] This patch for version 4.x and the patched Linux kernel 3.12.43 LTS both seem like sensible code to contemplate.


[Editor's Comment: Original Submission]

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by kaszz on Tuesday May 26 2015, @05:40PM

    by kaszz (4211) on Tuesday May 26 2015, @05:40PM (#188161) Journal

    How horrible. You escape both Systemd and ext4 while all these Linux fans suffer. And think also about those suffering by NTFS. ;)

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: -1, Flamebait) by Anonymous Coward on Tuesday May 26 2015, @07:21PM

    by Anonymous Coward on Tuesday May 26 2015, @07:21PM (#188204)

    You're an idiot if you're still running Linux in 2015. Even for work. There's just no reason anymore.

    Why did people ever run Linux?

    1. It was geeky
    2. It was better
    3. It was open/libre

    None of those things are true anymore. Get over it. The bums lost!

    • (Score: 0) by Anonymous Coward on Tuesday May 26 2015, @09:41PM

      by Anonymous Coward on Tuesday May 26 2015, @09:41PM (#188291)

      The parent isn't Flamebait. It makes a good point. Linux was the past. FreeBSD is the future. There is no reason to use Linux today.

  • (Score: 3, Interesting) by mr_mischief on Tuesday May 26 2015, @10:13PM

    by mr_mischief (4884) on Tuesday May 26 2015, @10:13PM (#188315)

    I agree systemd has its rough edges. I'll also agree it's trying to grab too many different parts of the system. I'll tell you three things that are really nice about it, though, and why it's loved by certain people.

    First, you get a standard daemon watchdog/respawn for free with your init system. There's no more whiling away looking at the pros and cons of a dozen different watchdog superdaemons. Just let systemd do it. If it needs to be improved, systemd has enough users that there will be pressure to accept the best patches which will then improve everyone's lot.

    Speaking of just letting systemd do things, do you write startup and shutdown scripts for daemons? I do. It's a pain. It's a bigger pain across multiple distros. It's an even bigger pain still if you have to make them work with multiple shells. With systemd you get nice declarative syntax for systemd unit files. There's no muss, no fuss, and plenty of just getting stuff done.

    People bitch about systemd and binary logging. Yet it doesn't preclude you from also running syslog, rsyslog, or ulog, or whatever else. Plus, those binary logs get checksummed. That's really handy for auditing.

    So, who likes systemd? Package maintainers do. The startup and shutdown of a daemon process, including watching and restarting it, is damn near template-filling rather than shell scripting. DevOps people like it for that reason, too. It complicates some things, but it does so to make other things dead simple. Those things matter to the people building the distros. I think that's why so many distros use it now.

    • (Score: 2, Insightful) by Placenta on Tuesday May 26 2015, @10:21PM

      by Placenta (5264) on Tuesday May 26 2015, @10:21PM (#188321)

      How does any of that apply when the system in question refuses to boot because of a failure of systemd?

      • (Score: 2) by kaszz on Tuesday May 26 2015, @10:37PM

        by kaszz (4211) on Tuesday May 26 2015, @10:37PM (#188332) Journal

            §1 Systemd is flawless and the solution to everything(tm)

            §2 If rule (1) should for any reason be wrong. Just ask Poettering about it's validity.

        ;-)

      • (Score: 2) by mr_mischief on Wednesday May 27 2015, @05:04PM

        by mr_mischief (4884) on Wednesday May 27 2015, @05:04PM (#188693)

        It doesn't apply if the init system fails to initialize the system. How often does that happen, though? We run plenty of CentOS 7 and I don't remember having any failures to boot.

        • (Score: 1) by Placenta on Wednesday May 27 2015, @09:50PM

          by Placenta (5264) on Wednesday May 27 2015, @09:50PM (#188795)

          I had it happen to me numerous times while running Debian systems that used systemd. I finally got fed up, and moved these Debian systems to other OSes.

    • (Score: 0) by Anonymous Coward on Wednesday May 27 2015, @07:09AM

      by Anonymous Coward on Wednesday May 27 2015, @07:09AM (#188496)

      First, you get a standard daemon watchdog/respawn for free with your init system. There's no more whiling away looking at the pros and cons of a dozen different watchdog superdaemons. Just let systemd do it.

      Just let systemd do it. One Microsoft Way.

      Speaking of just letting systemd do things, do you write startup and shutdown scripts for daemons? I do. It's a pain.

      Yes. The brilliance of simple shell scripts controlling the entire system was one of the things that brought me to *nix in the first place.

      • (Score: 3, Insightful) by mr_mischief on Wednesday May 27 2015, @05:16PM

        by mr_mischief (4884) on Wednesday May 27 2015, @05:16PM (#188699)

        The simplicity of shell scripts controlling the system has pros and cons. The concept is simple. The scripts themselves often aren't very simple. There's definitely room to argue for scripts over unit files, but also vice versa.

        The bit about Microsoft is a false association, though. Unit files are plaintext and simple. There's a separate one for each service. They aren't some binary blob locked in some poorly documented binary file together along with all the other information about all the other part of the system.

        One thing Microsoft always has had right, though, despite their crap security record, huge code bloat, and illegal business practices, is that developers matter. On most Linux distros, package maintainers matter, too. Having a simple way for maintainers to package all that third-party open source code means faster turnaround. That means faster security fixes. It means quicker access to new features. It potentially more packages available. Making it easier for third parties to build packages makes it easier to deploy things not already packaged, especially via configuration management.

        There's still a lot about systemd that sucks. Pragmatically, though, rather than ripping out all the stuff out there running on Linux and getting it working on FreeBSD, NetBSD, or OpenBSD in production and rather than forking one's own non-systemd Linux distro, most people are going to deal with what RedHat, Debian, and Ubuntu have given them. They'll try to find the best parts of that and take advantage of those even as they curse the rest of the changes as unnecessary fluff. People getting real work done five or six days a week don't have much choice.