161
ext2: mark as deprecated - kernel/git/torvalds/linux.git - Linux kernel source tree
(git.kernel.org)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Sure, as soon as there's a stable replacement available.
I wouldn't put my mission-critical file server on BTRFS.
Oh, but I and a lot of people do and it is way more reliable than ext* filesystems ever were. Maybe ZFS or XFS is more your style then? Ext4 is very, very prone to total failure and complete data loss at the slightest hardware issue. I'm not saying you should rely on any filesystem ever, backups are important and should be there, the thing it that recovering from backups takes time and the amount of recovery that ext forced me into over the years isn't just acceptable.
Do you have a source for the ext4 failure stuff? I use ext4 currently and want to see if there's something I need to do now other than frequent backups
ext4 is still solid for most use cases (I also use it). It's not innovative, and possibly not as performant as the newer file systems, but if you're okay with that there's nothing wrong with using it. I intend to look into xfs and btrfs the next time I spin up a new drive or a new machine, but there's no hurry (and I may not switch even then).
There's an unfortunate tendency for people who like to have the newest and greatest software to assume that the old code their new-shiny is supposed to replace is broken. That's seldom actually the case: if the old software has been performing correctly all this time, it's usually still good for its original use case and within the scope of its original limitations and environment. It only becomes truly broken when the appropriate environment can't be easily reproduced or one of the limitations becomes a significant security hole.
That doesn't mean that shiny new software with new features is bad, or that there isn't some old software that has never quite performed properly, just that if it ain't broke, it's okay to set a conservative upgrade schedule.
Oh ok, that makes sense. Thanks!