When I started using Linux (1999), ext2 was the filesystem, & whilst I had some errors that needed fsck running occassionaly, I think it was down to me being a 'noobie'. I stayed with ext2 until ext3 was the suggested filesystem with its journalling which worked well for me, so the main reason that I changed to ext4 was that it supported SSD disks better. The 'ext' filesystems have worked well for me so there is no reason to change to any other.

(I also use (Free)BSD at times, & favour UFS on that system.)

N.B. Microsoft filesystems are not Linux filesystems!

ext4 is a good default in a very self rewarding development+usage cycle. More users exposes more edge cases, which tend to get fixed very quickly. It's preferred over the other exts since it uses extent based allocation which is much more efficient both performance and allocation space wise. Metadata checksumming is not yet finished.

XFS is the default in RHEL/CentOS 7. Yet it's found in more consumer NAS appliances than servers, so it's not just for servers. It too uses extent based allocation, and is well optimized to run on both hardware and software RAID in both consumer and enterprise environments. It benefits from parallelization by spreading allocation groups across multiple devices, even when arranged in linear/concat which can be an advantage for some workloads. It's metadata checksumming is considered production ready since kernel 3.15 and xfsprogs 3.2, but it still optional.
http://lwn.net/Articles/476263/
https://git.kernel.org/cgit/linux/ke...efs/tags/v3.15

Btrfs is now the default in openSUSE 13.2. Metadata and data are checksummed by default. The biggest barrier to entry is that in case of problems, there are many repair methods that are sequence sensitive and the maturity of these repair methods is in constant flux. It's unlikely you'd experience fs corruption needing repair as it does a good job repairing most problems at mount time; but it almost instantly goes off the rails for the user if it can't and requires quite esoteric knowledge. e.g. the current order, subject to change, is:
a. Normal mount
b. Mount with -o recovery
c. Mount with -o ro,recovery (and at least get backups updated)
d. btrfs-zero-log which will mean possibly up to 30 seconds of data being lost
e. btrfs check (same now as btrfsck) without --repair, and post to the list

Up until btrfs-progs 3.17, things often get worse with 'btrfs check --repair' so you still kinda need to be using very recent kernels and user space tools. You probably want to default to posting to the linux-btrfs@ list by step e (above) at the latest. And very judicious with backups, especially if you will use more advanced features like multiple devices. There are several additional repair, debug, and file scraping (extracting files from an unmountable fs) commands I'm not listing on purpose. The "if things go wrong" situ on Btrfs is daunting, you can't be expected to know such things and there is work in progress to consolidate repair commands.

Each kernel release has hundreds, sometimes over one thousand Btrfs commits. You won't see nearly that much change occurring with stable systems like ext4 or XFS. If you need Btrfs like features and don't want to be on a development list possibly being asked to test very recent (mainline rc) kernels, you should look at open-zfs.org / zfsonlinux.org.

LVM2 it's not a filesystem on its own, and its feature set runs into the totally esoteric, while not particularly user friendly either. But some new features for those not up to date: LVM now implements its own tools and on disk metadata format for raid 10, 4, 5 and 6; lvmcache combines performance of SSD and capacity of HDD into a single volume; thin provisioning enables creating virtual size LVs that exceed the size of the underlying physical space, reducing the need for fs resize, enables sharing of extents between volumes so they only use the physical space they actually need, snapshots are thin volumes: are fast, reserve space is not needed since any writes draw extents from the thin pool as needed, permits snapshots of snapshots, and each snapshot is independent so you no longer need to merge snapshots back to origin - just delete the original and retain the current snapshot as the "new original" with updates intact.

I can highly recommend two new projects for getting a better view of, and management of some of the more advanced linux fs storage capabilities: system-storage-manager, and blivet-gui. One is CLI and attempts to create a consistent nomenclature of commands regardless of what raid, pool, and fs technology you use; and the other looks similar to gparted UI but is leveraging a ton of LVM, LVM thinp, mdadm raid, and Btrfs features that gparted doesn't.
http://fedoramagazine.org/manage-you...th-blivet-gui/
http://storagemanager.sourceforge.net/

The main thing I use ssm for is the invaluable 'ssm list' command which gives both broad physical device, partition, pool, volume, subvolume, fs breakdown for a neat big picture and detail view of a system's storage stack.

What fs do I prefer? I prefer one matched for the use case, time and mental budget. Sometimes it need to just be default ext4. Sometimes it's XFS on LVM thinp. Often it's Btrfs since I like the advanced features while still having a very sane command structure (LVM is badass but my god the command structure makes my head explode sometimes).

1 members found this post helpful.

Hi,
I am reporting the experience of my Dell B120 using Ubuntu Presise 12.04.
I have used this OS for almost a year now, no blips, stutters, or crashes... Wow. This is definately way better than any windows OS I have used. I am very proud of Linux and their communities making the Linux Distros for all of us to use since the expiration of Win XP. That OS, Win XP was the best ever OS MS ever made and wow, Why in the world did they expire it's use and support to the whole world that was so dependent on this particular OS? And now that I was forced to scramble for another OS, ran into Linux Mint Mate and viola! My wife is back in business... and I was so excited of learning to be a Linux user that I now have a used Dell B120 with Ubuntu loaded for $100 and am so happy with it and the OS that I wished I had gotten into Linux 20 years ago..... I now have 5 raspberry pi's and a Beaglebone Black... And those little toys are awesome. So, I am learning Raspbian, Ubuntu Presise, Mint Mate 17, and Tahrpup. And man, this is really sweet, Linux community. Thank you.
Bill

I've never tried to use FAT32 (except on USB sticks) but I'd be very surprised if you could set user, group and the executable flag properly.
FAT32 doesn't support symbolic or hard links either...

btrfs on my installed systems.

ext2 when running live usb with persistence.

over the years i've used reiserfs, xfs, and ext3 in linux for work.
my experience has been:
- reiserfs has given me problems when doing improper shutdown or power failures the operating system disk would be corrupted and go through boot up problems. more than once i've had to reformat and reinstall the OS. never used reiser on a mounted data partition
- never used ext4 since the operating systems i've used never supported it. right now i use Novell SLES 11, and sles 12 just came out and finally support it. i also have some synology NAS boxes and they use ext4 exclusively, but i have little to no runtime on them to comment yet.
- ext3 has been good on os partition and for mounted data volumes. never really had a failure due to corruption, will occasionally get some automated file system fixing on bootup but never lost data or failed to boot. good thing is it linux (sles) does automaticed/forced disk check after 30/60 days or whatever which gives warm fuzzy, bad news is it does that unless turned off and for large drives or raid volumes can take a very long time. when i format a 10+ disk raid5 volume around 5TB the disk checking takes overnight.

never really had a problem with XFS. i have no good benchmarks to prove it but i can't say it's slower than ext3/ext4 either. and i've used xfsrestore and xfsdump and it does work well. only reason i voted for and use ext3 on an OS partition is because "it's the traditional choice" for linux and used/supported the most by the community.
to be objective about it i'd say XFS from my experience is the best or a very close second to ext3.

i just starting messing with SLES 12 and created the disk using BTRFS. not at all impressed. i don't see what the hype is about. it seemed slower copying files from one folder on the disk to another, and the fstab file is certainly more complicated with a bunch of @ mount symbols.

ext4, it's the default in most modern linux distro's, and quite frankly my needs aren't sufficient enough to see a difference if I switched so it's easier just to use the default.

As I've had some troubles on big volumes with the (default out of the box these years) ext4, I'm currently using the ext3 for internal storage (HDDs with default options, flash drives with noatime option) and ext2 for external storage (like other guys here, I've had my share of trouble with ext3 journals on those).

Besides the few out-of-the-line cases of JFS use (going as far back as the end of the 1990s on OS/2 and 2001/2002 on Linux), I've never used any non-mainstream filesystems on Linux and BSD.

Am I missing anything good? If I understood right that study mentioned earlier, it seems JFS might be a good choice for nowadays solid state media. What about the HDDs? Call me egoist, but I don't feel like experimenting on my data with things like btrfs etc.

I prefer ext4 file system due to various reasons. It didnt' trouble my boxes during unexpected shutdown.

Btrfs, because the ability to snaphot the system.

How are you using FAT32? Which filesystems?

EXT4 seems to handle crashes well. My wife's laptop crashes daily, sometimes multiple times a day. It doesn't charge and the power cord is messed up. Still the system boots and runs fine. EXT4 even handled crashes during stress testing on my new system.

I had tried ReiserFS on my laptop some years ago. After one crash (dead battery), the filesystem was completely trashed.

The only issue I've had with XFS had something to do with conflicting/duplicate UUIDs, but was easily corrected. I only had one HDD with XFS though.

FAT32 needs to die already.

As you can see from my choice of distros, I want stability rather than innovation, and with half-empty 40GB drives, I don't need anything fancy. On the HDs I stick to ext3, while USB sticks are ext2.

Usually, ext4 as it is the default filesystem for most distros now but at work a smattering of ext3 and zfs (depending on the application).

On that note, ext4 has been fantastic through power failures for me as well. I have an autonomous data acquisition system on a fit-PC2. It pulls in data at around 3 MB/s constant, never-ending, dumping straight to disk. And being an autonomous system, it has no control over its power situation. Every single time it boots up, it gets shut down hard WHILE WRITING 3 MB/s to the disk, every time. I think the only time it's seen a "poweroff" or "shutdown -h now" command was during the initial setup a couple of years ago. Despite these horrific conditions, in two years, many terabytes of data written, and probably around 1-200 hard mid-write shutdowns, the filesystem is still perfectly fine. No file corruptions, no filesystem corruptions, no errors or angry messages of any kind.