Why is XFS not more popular? Are there are any concerns with XFS still?

Posted by ECrispy@reddit | linux | View on Reddit | 288 comments

This is for home desktop usage, not servers/data centers where XFS is far more common. performance - in every test I could find, XFS is near the top, beating btrfs/ext4. Its esp good for parallel workloads and almost everything on a modern desktop is like that. The only perf concern I read about is it used to have higher cpu usage for updating metadata but I believe thats been fixed and no longer relevant? (I think for most users, performance in benchmarks may not be noticeable and other features matter more, but its still an important consideration) SSD/OS installs - XFS is almost as fast as f2fs for these. I see no reason why anyone would use f2fs on anything other than a sd card or on any NAND device with wear leveling. CoW/snapshots - this is no doubt a very powerful feature of zfs/btrfs. But I see very little mention of reflinks/snapshots on XFS which can achieve a lot of this. They are not atomic but enough to satisfy a lot of use cases. I don't see support for this in the usual tools like snapper/timeshift either. other features - dynamic inodes (on ext4 an inode for every 16kb/256kb is wasteful, even if most people never notice it), automatic fsck, journalling (sure, copied from ext3, but thats not a bad thing) stability/reliability - I don't think there should be any doubt about this. Its a proven enterprise class fs with a hallowed pedigree and reputation, is now backed by RHEL and has probably seen more active development than most other file systems.  The biggest factor seems to be that the default ext4 is good enough, and frankly most people will not care or know about, and should not care, about the underlying fs. There are also distros like Fedora/OpenSuse that used to use XFS as the default and have switched to btrfs. I don't know of anything that uses XFS as default except unRaid now - unRaid is used to manage TBs by home users and that probably says something.  The only con I've found is that supposedly XFS doesn't handle hw failures. Even on this I found no consensus - some people say its risky and can corrupt with no recovery, others say even with a forced shutdown its safe. I'm not sure if its any less robust than ext4/btrfs? Is this actually a concern these days?

Reply to Post

Reply

288 Comments

[-]

Moscato359@reddit

Most people don't care about their filesystem and use the default

Reply

[-]

WingedGeek@reddit

I use reiserfs. It slays.

Reply

[-]

yochanonHAirgunII@reddit

Sorry I'm so late to this. I profoundly agree that reiserfs is fantastic. I started using linux in the year 2000, after 4 years of M$ screwing me over \*every\* time we had a brown-out or black-out (I'd not heard of UPS's yet). Found 'linux' in a search for 'OS's other than M$' (I'd also only had an inkling of linux/UNIX also). Stuck on dial-up, I didn't care how many days it took to download a distro to try. Went through 4 distro's before finally settling on SuSE. It worked and I was able to use it for pretty much anything I needed at the time, so I kept it for about 4 or 5 years, until they decided to work with canonical \*and\* M$, then I dropped it like a red hot coal. Back to distro-hopping. It took a few months, because I wanted to make sure it was going to be something I would understand easily enough to use and learn on and eventually settled on Slackware 10.1 and I've remained a Slackware user since then. The file system was something completely unheard of and new to me, but I did a little reading, enough to get myself almost permanently cross-eyed (ha ha) but understood enough to make at least what was hopefully a decent idea of what I wanted to use. After 10.1 I have stuck with reiserfs, and through the years since then I've used it on every install I've done of Slackware and playing with other distro's just to see what they're like. Here in the area where I live, brown-outs are \*expected\*, often two or three times a week and similarly when they happen on that day. Black-outs are also expected, often up to 4 or 5 times a month. Before I learned about and was able to afford to get UPS's reiserfs has saved my hdd's, sdd's, and nvme's. When it happened while using M$, every time it happened I lost everything and had to reinstall almost in tears (I was also still not familiar with ways to back up my system and the things I wanted to keep, other than <shudder> ZIP drives - which also, as many know, turned out to be a mistake too. No, reiserfs would reboot and everything be just fine, like a champ, \*every\* time brown-outs and black-outs happened. I never worried anymore and realized after about a year or so that the tension of being on my computer and doing what I wanted and if something happened to the power, I didn't sweat it. It was a darned good feeling. Unfortunately, now I find that even Slackware is going to drop it from any future versions after 15.0. Which means I'm on my last version of Slackware and will use this system until someone or something better comes along. Yes, btrfs is 'supposed' to be good, but I've yet to read about or hear great things about its use, same with ext4, I've only heard that it's only barely better than ext3, which didn't impress me the couple of times I tried it. Yes, reiserfs was developed by a dude that murdered his wife and the fs is old and no one working on it. I don't care. I use it and will continue to use it until, as I said, something better comes along that impresses me like reiserfs did compared to the ext's and other fs's.

Reply

[-]

LordChaos73@reddit

In the end, it was a killer's filesystem

Reply

[-]

xeoron@reddit

every harddrive I used it on it killed within 1 year.

Reply

[-]

Anonymo@reddit

My drive went missing for a while.

Reply

[-]

flarkis@reddit

Tail packing was a godsend for all us gentoo users back in the day. Almost all of us had our ebuild trees on reiserfs and our homes on ext3. Luckily all the modern file systems are pretty good at handling small files.

Reply

[-]

blenderbender44@reddit

Why whats good about it?

Reply

[-]

INITMalcanis@reddit

It operates above head height

Reply

[-]

mb2m@reddit

True, modern architectures are complex. The basics like the fs, kernel parameters, memory management should just work.

Reply

[-]

BosonCollider@reddit

Yeah but ext4 does not support reflinks (instant copies), and file copies being instant is something that a regular user may actually notice if the file manager UI copy made use of it.

Reply

[-]

Moscato359@reddit

I actually do a fair bit of customization, but I also work on insanely large scale, but most people don't need to care

Reply

[-]

mb2m@reddit

True, well our security department is keen on tweaking quite a sysctl settings. I wonder how not doing this can be an attack vector when 99 % of company leave them default but better safe than sorry I guess…

Reply

[-]

Moscato359@reddit

sysctl settings are generally tweaked to meet complicance regulations, against vulnerabilities that were fixed in the kernel a decade ago Things like how to handle icmp attacks Fedramp, iso27001, etc all require the tweaks, but they're basically pointless I mostly do tweaks to meet our performance requirements

Reply

[-]

HermeticPurusha@reddit

I configure plenty of sysctl for telco companies, it’s not only for security, you can do plenty of tweaks for the IP stack.

Reply

[-]

NeverMindToday@reddit

Note: ISO27001 won't require stuff like that - it doesn't go into implementation details at all. It's a standard for how you write and update your own policies and processes, then certify that you follow them. Now, if your org decided for whatever reason to put those details in their own security policy and process, then ISO27001 will ensure you have to stick to that. I've gone through getting ISO27001, but we had none of that - we had a CISO who understood not to hardcode implementation details in high level policies.

Reply

[-]

InsensitiveClown@reddit

You should tune your kernel and even compile it. You have to remember that distributions must cater to a huge number of use-cases, and necessarily, they will be sub-optimal in all. That's just the way it is. Some time ago I ran into some crazy USB I/O DAC latencies that I could only solve after compiling a kernel for real-time use with some bells & whistles, and configuring a few kernel parameters. Tuning a kernel for production is important. If you have a server, you don't need fast interactive response rates, and certainly not RT kernels. You want throughput. The opposite is true for desktop where responsiveness is paramount, and in some use cases, such as audio processing, or VJ, latencies must be extremely short.

Reply

[-]

archiekane@reddit

Are we talking scale as in size of pools or just lots of mirrored copies of the same systems (clusters of machines)?

Reply

[-]

Moscato359@reddit

Multiply what you are envisioning with that question by 1000x

Reply

[-]

archiekane@reddit

Data centre architect?

Reply

[-]

Moscato359@reddit

I work in a data analytics company processing data at extreme scale (Imagine ingesting every document ever made by your customers) I'm in the storage department

Reply

[-]

sylfy@reddit

Found the Adobe employee.

Reply

[-]

Moscato359@reddit

lol fuck adobe I don't deal with consumer data at all, its all business to business stuff

Reply

[-]

archiekane@reddit

Ah, that explains it. Curious though, if you have time for questions?

Reply

[-]

Moscato359@reddit

I can answer questions about the industry, which don't violate a NDA, so I have to be a bit vague

Reply

[-]

archiekane@reddit

Okay: Base OS on bare metal is what for hypervisors? The SANs run what OS? Filesystem of choice is? How is that FS configured at scale?

Reply

[-]

Moscato359@reddit

linux on azure impossible to tell you because its a fully custom filesystem we wrote in house

Reply

[-]

ECrispy@reddit (OP)

I specifically said the exact same thing. My point is - isn't XFS a better choice?

Reply

[-]

Torches@reddit

In a business environment extending and shrinking FS is a key feature not negotiable.

Reply

[-]

clipcarl@reddit

> In a business environment extending and shrinking FS is a key feature not negotiable. It depends on your definition of "business." In small or perhaps even medium-sized businesses maybe. In enterprise-class businesses you properly plan and validate the size and performance of arrays up front and when you outgrow them you simply build a new one that meets your new requirements. Haphazardly shoving more drives into an existing array to extend (or removing drives) invalidates all the performance validation you did up front so admins who like being employed would resist.

Reply

[-]

wonkynonce@reddit

Yes, and Red Hat defaults to XFS- and that makes it the default for most big companies

Reply

[-]

racerxff@reddit

Yes, but your title asks why it isn't more popular. That is the answer.

Reply

[-]

ECrispy@reddit (OP)

well for the casual user they will simply choose the distro and thats it. most wont even know that a fs is let alone the choices. I suppose my qn could be more targeted towards those who actually know what these are, e.g. advanced users, distro maintainers etc. Clearly there's growing mindshare for btrfs and more distros are switching to it, probably as a modern/poor mans ZFS (which will never in Linux mainline) because it has the most hype, even though I doubt hardly anyone uses its features.

Reply

[-]

Moscato359@reddit

Hot adding and removing disks is not a feature that is rarely used, which is a major benefit to both zfs and btrfs xfs is not good for that

Reply

[-]

Jward92@reddit

It seems like you already know the answer based on this comment tbh. Distros that cater to user who won’t care about Filesystem features go with a fast stable one like ext4. Distros that cater to users who care about Filesystem features use the new hotness, like btrfs or zfs.

Reply

[-]

draeath@reddit

You really should be asking distribution maintainers then, since they're the ones who make this call. The stuff I run tends to default to XFS or BTRFS, I find. Others just stick to ext4 by default because it's a sane reliable choice - as is XFS - but there's momentum there. If it's not broke, don't fix it. That sort of thing.

Reply

[-]

the_abortionat0r@reddit

Not quite true. Even windows gamers are starting to ask how btrfs can be used on Windows, though they don't like the answers.

Reply

[-]

Moscato359@reddit

hahaha, no Maybe like 0.01% of gamers have asked that, and the question got elevated on social media If you want a fancy special filesystem with all the main features of btrfs, on windows, that is refs, which already is 1 registry key away from being available it has copy on write, hot spares, ability to add drives whenever you want, or remove, etc

Reply

[-]

AndydeCleyre@reddit

I'm happy to use XFS on servers. I don't care about snapshots. The main blocker for me using XFS at home is lack of compression. Though it's been a while, I have been burned by BTRFS. I am impatient for bcachefs to mature.

Reply

[-]

Llamas1115@reddit

RIP

Reply

[-]

Nice_Ad8308@reddit

Distro installers not always provide other options during instalation. Often only limited to Ext4 for example (linux mint). If you want to use btrfs or Xfs you need to do some manual work on order to get it working. I hope these distros will also provide native support for more file systems in general. Otherwise the world will never change.

Reply

[-]

GolbatsEverywhere@reddit

> b)supposedly XFS doesn't handle hw failures. Even on this I found no consensus - some people say its risky and can corrupt with no recovery, others say even with a forced shutdown its safe. I'm not sure if its any less robust than ext4/btrfs? Is this actually a concern these days? I see you are unfamiliar with [bitrot](https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/). It is very much still a problem and in my opinion is the single most important reason why distros are now defaulting to btrfs. It's not fun to discover that a file is corrupted. Discovering that also all of your backups of the file are corrupt too, because your filesystem allowed the backup program to read and back up the corrupted data, is especially not fun. P.S. Fedora desktops never defaulted to xfs; they went from ext4 -> btrfs. But Fedora Server uses xfs in order to match RHEL.

Reply

[-]

lupinthe1st@reddit

Not an expert: on ext4, how can a file with corrupted data slip through every layer of hardware and software parity checking without giving I/O errors while being copied into a backup? How are btrfs checksums different from hardware HDD checksums? I had a faulty SDD once that corrupted a bunch of data sectors randomly, in old files not accessed for some years. The OS correctly gave me I/O errors when I tried to read the data while trying to do a backup.

Reply

[-]

primalbluewolf@reddit

> How are btrfs checksums different from hardware HDD checksums? Do any regular HDDs implement their own checksum?

Reply

[-]

Ryccardo@reddit

Yup, it's how they can identify bad sectors (that modern - since about 1993 - drives auto-remap up to a point, when there are no more spare sectors you start getting BBK errors at the ATA level, which the operating system is supposed to handle on its own - full format or scandisk surface scan on DOS/Win9x, the option to integrate a badblocks test in mke2fs) The mid 2000s push for 4k physical sectors by manufacturers is so that 3 out of 4 ECC areas can be removed = legally advertise more storage with the same physical disk and heads and electronics

Reply

[-]

Impressive-Care-5914@reddit

They use ECC.

Reply

[-]

GolbatsEverywhere@reddit

Good question. I don't know the answer, though. Now I'm questioning the importance of filesystem data checksumming. Somebody, please educate us!

Reply

[-]

sparky8251@reddit

Hardware can lie pretty easily. It just has to be busted but still functional and it can write different things than you told it to. Then we can get to the fun of cosmic rays, where it can flip bits on drives and your RAM without you knowing causing both reads and writes to fail even without bad hardware... Having additional checks for all these sorts of things and NOT trusting what the hardware tells you is just smart if the data is important to you. Thats exactly why ZFS, BTRFS, ReFS, and now Bcachefs exist. They are filesystems that dont trust the hardware of the computer since its long been known to have odd failures and thus has proven to be untrustworthy.

Reply

[-]

ipaqmaster@reddit

The host disk driver tells the disk's onboard controller, or a raid card, or something disky to perform a write operation and whatever controller that is returns success. Raid cards lie and may not have actually committed the write to the real disks yet. So pulling the power will result in data corruption without a battery backup for a safe shutdown. Disks can fail, though often predictibly with S.M.A.R.T errors to help know the early stages of needing to replace them in redundant arrays. Host issues can occur. Power supply problems causing errors, bad data cables, bad power cables, drawing too much on a system. Bad hardware. Memory problems (Less likely without catastrophic system failure being apparent). And there's bitrot, where reading a data block from a disk today may not read out the same value in 0.1, 1, 5, 10 years and you have corrupted data just from bitrot, an expectable failure as disks degrade. ZFS stores a checksum for all written records and can recover from the error in redundant arrays. Even on a single disk configuration it can still *detect* bitrot thanks to this checksumming. Always take backups. You can also experience any of these components connecting to a disk or the disk itself may be in the middle of a write operation and the power gets pulled. That block is now full of \x00's or a truncated write and can be considered corrupted. A similar problem was common in the slow 512MB USB flash drive era where flushing writes was slow and people often pulled them out with critical documents which were not finished writing. Same impact but not quite the same cause as a write being interrupted in-place. And then there's the write hole. From [here](https://serverfault.com/questions/844791/write-hole-which-raid-levels-are-affected) > "The write hole is a simple concept that applies to any stripe+parity RAID layout like RAID4, RAID5, RAID6 etc. The problem occurs when the array is started from an unclean shutdown without all devices being available, or if a read error is found before parity is restored after the unclean shutdown." Copy on Write filesystems such as ZFS tackle this by ***never*** overwriting data in-place. Always somewhere else. If everything looks good then it finally updates a chain of pointers from the master blocks (Which are also stored redundantly) to the new data. And yet if you make the mistake of using a raid card that can still lie about things it'll eventually mess all of that up. ZFS is pretty good at preventing that kind of failure too but you should never be using a raid card with ZFS. ZFS is the software raid and lying to it takes away that resilience.

Reply

[-]

lusuroculadestec@reddit

Silent errors will happen when everything in the chain reports it wrote something one way without error but an actual bit gets flipped on disk. When a file is read, the system just reads the data as-is. There isn't anything that inherently knows bits were flipped when they were written. By contrast, if the file system itself has the knowledge of what the data should be, it is more easily able to ensure that the bits on-disk match what it expects to be on-disk.

Reply

[-]

malikto44@reddit

I had this happen on a ZFS volume. This was a machine that had two SAS controllers which saw the same drives and used multipathing. One of the controllers glitched and wrote garbage to a chunk of the array at random. Because it was the controller that did it, checksums were valid for the block tier. However, ZFS caught and was able to correct it, as I had the data on `RAID-Z3`, because I wanted triple parity due to the value of the data. Were I using `md-raid` or something without checksumming, the damage caused by the controller would not have been detected.

Reply

[-]

slaymaker1907@reddit

I don’t think it’s that straight forward. If the files in question have their own integrity mechanisms, they can often repair themselves as long as the file system doesn’t get in the way. A git repo is probably a good example of this where additional corruption detection often just ends up being harmful. Let’s be honest here as well and remember that most users of desktop Linux are developers. As a dev, I want my FS to be as fast as possible since it can often end up being a bottleneck. I also don’t care too much about integrity since stuff that matters is stored in the cloud and has versioning. I’m also extremely skeptical of the premise that that bitrot just sneaks up on you. I’ve had drives go bad before and they typically start having a bunch of sectors go bad all at once. It’s not subtle at all. In fact, I think I’ve seen more subtle issues with memory and than with drives. SSDs don’t just leave data sitting in flash for extremely long periods of time. Things get moved around constantly due to GC and wear leveling assuming you continuously writing at least some data.

Reply

[-]

Negirno@reddit

Also, most backup tools usually just look at the modifydate attribute, so if a bit randomly flipped on a file which you backed up beforehand, the erro unlikely to get to infect the backups.

Reply

[-]

GolbatsEverywhere@reddit

> I don’t think it’s that straight forward. If the files in question have their own integrity mechanisms, they can often repair themselves as long as the file system doesn’t get in the way. Your text files can repair themselves? Music files? Images and videos? PDFs?

Reply

[-]

slaymaker1907@reddit

If the text file is in a Git repo, then yes. Even if it’s not, you can often fix those manually. For other kinds of files, they could still be usable depending on if they’re compressed and how the compression works.

Reply

[-]

GolbatsEverywhere@reddit

OK. I like data that's not corrupted....

Reply

[-]

ECrispy@reddit (OP)

No I know what bitrot is - its only handled by checksumming of data, only done by btrfs/zfs in consumer fs. These will work fine for live systems. They do nothing for backups taken on offline disks whcih are also subject to bitrot of course. The best solution for that I know is snapraid, and running regular sync/scrub. Also matches the use case of backups much better.

Reply

[-]

GolbatsEverywhere@reddit

If the backup is stored on btrfs, then of course the backup is protected. But the primary way for corrupted data to enter a backup is to simply back up corrupted data. > The best solution for that I know is snapraid, and running regular sync/scrub. Also matches the use case of backups much better. If you're doing advanced stuff like this, then defaults no longer even matter. 99% of users do not know what snapraid is (I have certainly never heard of it) and need good defaults.

Reply

[-]

chaos_theo@reddit

See [https://discussion.fedoraproject.org/t/xfs-with-external-disk-for-journal-metadata/109516](https://discussion.fedoraproject.org/t/xfs-with-external-disk-for-journal-metadata/109516) with howto for hybrid xfs on raid1+raid6 for splitting metadata and data, benchmark tool and results - compare with your own.

Reply

[-]

Maipmc@reddit

Honestly, the inability to shrink a partition is a complete deal breaker for me. And seeing how many new linux users sometimes choose to dualboot even after installing, i would never broadly recommend a filesystem that doesn't let you do that. Oh, and changing the size of partitions isn't by any measure advanced, there are plenty of really easy to use GUI tools that let you do that. Furthermore i want to add that i have nothing against xfs, i only use ext4 because i've learnt that using the default is the path of less resistance towards learning anything new. I would happily switch to anything else if i need to reinstall and feel compelled about the advantages, or my use case requires a different filesystem.

Reply

[-]

TomaCzar@reddit

Can't remember the last time I shrank a partition. I can't even remember the last time I formatted a partition rather than an LVM volume. Dreamers use BTRFS. Greybeards use ext4. Pragmatists use the distro default. They only people paying attention to the filesysyem with any level of real interest are n00bs, commercial (when it actually matters), and uber-nerds who read kernel lists and consider Teddy Ts'o and Hans Reiser household names.

Reply

[-]

keyborg@reddit

>Greybeards use ext4 Until I heard about XFS's concurrent read and write operations. Am researching for production deployment and this thread has been very useful. Especially the information regarding volume shrinking. Well noted and I can live with that. Thanks All.

Reply

[-]

AntLive9218@reddit

> Dreamers use BTRFS Hey, there may be still plenty of dreams, but checksums, reflinks, and optionally compression makes it a good candidate for likely the majority of setups already. Performance may not be the best, but with OS drives mostly being not constantly stressed SSDs with incredible bandwidth, trading off performance for more safety and features is quite sensible.

Reply

[-]

qwesx@reddit

Same. I used it years ago, but then, one day, I needed to shrink a partition. Or buy a new, bigger hard disk that I didn't really need. Since that day I refuse to use file systems that can't be resized/moved in every way. That event was significantly more pain than just using a slightly less efficient file system.

Reply

[-]

Motylde@reddit

You can grow or move XFS partition, you only cannot shrink.

Reply

[-]

cpt-derp@reddit

I needed to rearrange extents on an LVM2 to make room for a 4 TB that was to replace a 2 TB in a three SSD array on my laptop. It involved having to shrink the underlying ext4 partition. The end result is a linear LVM2 spanning 3 SSDs, The 4 TB with two 2 TB SSDs in RAID 0 underneath, so I have a contiguous 8 TB volume. Had I used XFS, the process would have taken days instead of hours because while I make regular backups, restoring 2 TB of data let alone up to 6 is not fun.

Reply

[-]

NatoBoram@reddit

That makes it basically unusable outside of USB-attached devices where you never expect more partitions to be created, and even then, does it have an official Windows driver? Otherwise, it's dead in the water.

Reply

[-]

forbjok@reddit

How often do you create a new partition on an existing drive though? The only reason I can think of to ever do that is if you are installing another OS to dual boot. For me at least, it's something that basically just never happens. Partitioning is something I generally do once when installing the OS and never change again until I reinstall another OS.

Reply

[-]

Fantastic_Goal3197@reddit

One potential use case other than duel booting is if you install more ram and want to increase the size of your swap partition so you can hibernate. You could get around that by using a buffer partition thats a different filesystem, but that requires planning and a little added inconvenience. Besides that thought thats pretty much the only reasonably common use besides duel booting I can think of.

Reply

[-]

Safe-While9946@reddit

XFS is widely used in the cloud. Oracle, and Amazon both default to XFS filesystems for block storage. Growing is kinda important, but shrinking? Not so much. Need a new partition? Just create a new block device. Done.

Reply

[-]

mike_elapid@reddit

I agree regards shrinking, this isn’t the 90’s anymore where you have to retrospectively save on space.

Reply

[-]

Majorlncident@reddit

That's on you

Reply

[-]

Hellohihi0123@reddit

Why ?

Reply

[-]

Majorlncident@reddit

It's not the fault of XFS if you set a partition size and then run out of free space and now want to shrink another. It never supported that when the partition was created. It sounds like it was assumed that it did.

Reply

[-]

Hellohihi0123@reddit

I mean, I don't blame people if they assume that a file system should be able to perform the basic task of managing partition. People should not even have to think about such a thing for any fs that is not in alpha testing.

Reply

[-]

chic_luke@reddit

This reasoning right here. I used ext4 on Arch because it was the de facto default as suggested by the docs. I run btrfs on Fedora Workstation because that's the default there. No issues.

Reply

[-]

Masterflitzer@reddit

you should always use a seperate disk for windows os, because else upgrades can mess things up i use an ssd for linux and one for windows, and another one for windows (have many games installed)

Reply

[-]

DrPiwi@reddit

just to be a little bit pedantic, you can resize, move, expand or shrink any partition. The real issue is if the file system on it can be modified without backing up and restoring the data on it. But even when file systems do support shrinking it is often dangerous and can leave you with damaged data. It is often better to create a new smalle partition and move the data to that and then consolidate the old partions into free space and then new partitons.

Reply

[-]

Intergalactic_Ass@reddit

>But even when file systems do support shrinking it is often dangerous and can leave you with damaged data. I've probably shrunk 1000+ ext2/3/4 FSs over my career and never had resize2fs damage the data. It's not dangerous if you do it properly.

Reply

[-]

royalbarnacle@reddit

If an FS may destroy your data during shrinking, I'd say it doesn't support shrinking, or at best it's a very beta feature they should embed behind clear warnings.

Reply

[-]

DrPiwi@reddit

All it needs to do to destroy data is clip one sector of a file that is in use and make it fall outside of the newly sized partition.

Reply

[-]

is_this_temporary@reddit

Ext4 can't be shrunk while mounted (though it can be expanded). So, for ext4, the "file that is in use" bit is not relevant. And while shrinking a filesystem is clearly a complex task, I would be surprised if there are many examples of bugs where resize2fs has kept an extent that was past the end of the requested size. Resize2fs doesn't handle the partition table though, so if you're not using something like GParted you can definitely accidentally make the new partition too small, or even accidentally change the starting block of the partition (as it's common to entirely remove the partition table entry and re-create it, even though parted and other common tools have resizing features to handle that for you). When it comes to live shrinking, my only experience is with btrfs, and with btrfs you can do *wild* things to data in files that are actively in use. You could have a 200 GiB qcow2 file, for an active VM, on one USB drive, then plug in a second USB drive (or iscsi block device, or...), "btrfs device add" the new drive, then "btrfs device remove" the original USB drive and btrfs will balance the data over to the new drive, and while the IO in the VM might slow down during the balance, it won't ever need to completely stop. Similarly, you can change the amount of redundancy, introduce striping (with multiple devices), turn compression on or off, "btrfs balance", all without moving outside of the expected and well supported use cases of btrfs. So, for btrfs, online shrinking isn't actually that strange of an operation at all. Any time you're reading and writing large amounts of data, you're more likely to run into hardware failures. I certainly hope you have backups of your important data even if you're not trying to resize your FS, but with a mature FS (which btrfs minus raid5/6 is) it shouldn't inherently be more dangerous than other operations involving similar amounts of IO.

Reply

[-]

ECrispy@reddit (OP)

my 2c - if you are going to install another OS and dual boot, its a good time to do a fresh reinstall of your main OS as well. I've never needed to resize partitions. how often do you do this and for what?

Reply

[-]

patrickbrianmooney@reddit

"How often do you need to do this?" seems like an off-topic question. "I want to have the option to do this if I need to" is not the same as "I am going to do this all the time." I don't spend most of my day having sex, but I sure am glad about my vasectomy.

Reply

[-]

Maipmc@reddit

Everytime i've tried to start using linux, after going solo linux when i ditched windows, and after my root partition became too cramped (now i no longer use a dedicated home partition) And there is still the posibility i reinstall windows so i would need to resize again. So... Enough times to warrant having the possibility. And about reinstalling... I hate doing that, i keep my os installs as long as i can, and just try learn to housekeep them. There is always an important modification or workaround i've made that i forget about, thus having to relearn it.

Reply

[-]

epic_pork@reddit

Can LVM bypass this issue somehow?

Reply

[-]

HeadlessChild@reddit

Not as long as you need to shrink the file system.

Reply

[-]

Nice_Ad8308@reddit

I think I should go with XFS next time.

Reply

[-]

anonkekkek@reddit

I swear by XFS. The reason: Real world desktop performance. Btrfs had some features I liked like checksumming how it did raid1, but damn it had unusably abysmal performance on HDD. Going through folders took way too long, opening files took way too long. Single drive, raid1, didn't matter. As an extreme example, a folder with 10k items took more than 10 seconds to load. Meanwhile XFS, despite being on a slower laptop drive, opened the same folder in 1-2 seconds. File exploring was butter smooth in comparison. I didn't know an HDD, let alone a laptop one is capable of that. That how Btrfs brainwashed me to accept abysmal performance. Never listen to them when they gaslight you telling you probably won't notice a difference with Btrfs. Lies. As for Ext4, XFS is still a bit faster in raw speed, but also Ext4 feels stuttery when it's under IO load. Apparently that's an ancient bug. XFS is butter smooth under high IO load. Also a lot of info about XFS is flat out outdated and wrong. It got a new metadata format a few years ago that completely fixes many assumptions people have. The benchmarks speak for themselves. Shrinking: There is experimental support for this already. You need to mind the allocation group size when creating the filesystem though. Personally I'm on mdadm RAID0+1 so I can tear down and rebuild one side at a time, so shrinking isn't a problem for me.

Reply

[-]

Mammoth_Control@reddit

> Also a lot of info about XFS is outdated and flat out wrong. It got a new metadata format a few years ago that completely fixed many assumptions people have and in fact it has flipped the table on Ext4 in many areas. The benchmarks speak for themselves. Interesting tidbit. I know a guy who worked with an F500 (at the time) who was a system administrator. They ran SGI IRIX back then, which was where XFS was developed. Anyways, the guy put together a 94GB RAID array which was obscenely large back then and hit some bugs. He ended up calling SGI to get some help and they couldn't believe the size of the array he was running. SGI ended up sending an engineer out because they could make updates to the filesystem and test it out in the field on such a large array.

Reply

[-]

ECrispy@reddit (OP)

fully agree. I have pretty old hw, some of which have hdd, or regular ssd (not nvme). I've tried a number of OSs inclyding Windows, many distros, and file systems. FS performance with a lot of small files as well as under load is one area which really reveals problems. e.g. NTFS is actually a very reliable fs but it becomes slow with lots of small files. btrfs had the promise of fancy features. in practive I never needed to restore to a snapshot, esp one takes automatically with an dnf/pacman update. What I did see was much higher writes to disk, which is slow on hdd, and bad for ssd. the much touted benefits of compression do not compensate for this.

Reply

[-]

xanadu33@reddit

XFS was heavily altered in the last 15 years an became much more resilient to failure. Make sure to upgrade to XFS v5 if you still use XFS v4. This has to be done manually: [https://linuxreviews.org/Prepare\_To\_Re-Format\_If\_You\_Are\_Using\_An\_Older\_XFS\_Filesystem](https://linuxreviews.org/Prepare_To_Re-Format_If_You_Are_Using_An_Older_XFS_Filesystem)

Reply

[-]

bmwiedemann@reddit

We are using xfs on download.opensuse.org's 40TB volume and had a few issues with it that caused hours of downtime. Twice the journal got corrupted. Then we found that with each resize it doubled the allocation groups and then there are different versions of xfs and migrating from the old one to the new one is not trivial. On another instance we got into trouble because two VMs were mounting the same block device. Sure, you should not do that, but I heard ext4 got safeguards for this case.

Reply

[-]

ECrispy@reddit (OP)

Thank you. This kind of real world feedback from experts is valuable. Are you still using XFS? what other options did you evaluate?

Reply

[-]

bmwiedemann@reddit

For my private stuff I use ext4 nearly everywhere and btrfs in the few places where I want snapshots. For VMs of SUSE and openSUSE we still use a lot of XFS. I looked through my notes and found [https://www.phoronix.com/news/XFS-Patch-For-Linux-6.3](https://www.phoronix.com/news/XFS-Patch-For-Linux-6.3) as well as a writeup from the 2023-05-23 outage: Due to several xfs\_growfs calls over the past years, we had 5672 AGs that is known to cause performance issues. mount rw takes forever. 28049280 inodes in one 36TiB filesystem does not help either. # dd if=/dev/vdf of=/dev/null bs=64k count=1000 1000+0 records in 1000+0 records out 65536000 bytes (66 MB, 62 MiB) copied, 2.13942 s, 30.6 MB/s We dumped the log with xfs\_logprint -t /dev/mapper/pontifex\* and found that it had a large number of pending transactions: # grep TRANS /tmp/logprint |wc -l 201889 For comparison: the nightly 00:10 snapshot only had 2 pending transactions To debug/recover we did * 07:17 nagios reported issues with mirrorcache and mirrorcache-eu, later download.o.o got stuck as well * bmwiedemann discussed with Andrii -> rebooted VM, did get stuck in emergency shell (failing mount /srv) * meet in jitsi * attempt to mount LVM * use ssl cert to setup fallback on stage3.o.o around 10:30 UTC and point DNS to it * move fallback to mirrorcache.o.o around 15:00 UTC to save bandwidth and use mirrors again (NFS disabled) * test with read-only snapshots on backup.i.o.o * read-only + norecovery mount * create another snapshot * xfs\_repair -L -P -n $dev # canceled because too slow at 5MB/s * xfs\_repair -L $dev # drop the XFS log ; faster at 50+ MB/s ; 8 disconnected inodes found * re-publish OBS repos * 18:43 DNS switched back for download.o.o and downloadcontent.o.o with pdnsutil edit-zone opensuse.org * 19:40 reload nginx on downloadcontent\* caches to use old downloadcontent as upstream again so that newly published files can be fetched (user in OBS IRC/matrix reported that issue) XFS postmortem: * mount recovery issue is reproducible on upstream kernels too (tested on v6.4-rc3) * bug in xfs kernel recovery code that leads to deadlock * the first phases of recovery take about \~3 minutes doing IO to storage due to the large number of transactions and pending items in the xfs log * after that, finalizing the recovery is caught in a deadlock * issue is known upstream, currently working on a fix \[1\],\[2\] * fix is indeed working (mount recovery completes in a timely manner on the offending partition) * presumably the conditions that allow for the possibility of this deadlock were introduced due to commit 06058bc40534 ("xfs: don't reuse busy extents on extent trim") (not confirmed) * not entirely clear how to reproduce this with an artificial workload (e.g. needs a fstest) \[1\] [https://lore.kernel.org/linux-xfs/20210428065152.77280-1-chandanrlinux@gmail.com/](https://lore.kernel.org/linux-xfs/20210428065152.77280-1-chandanrlinux@gmail.com/) \[2\] [https://lore.kernel.org/linux-xfs/20230519171829.4108-1-wen.gang.wang@oracle.com/#t](https://lore.kernel.org/linux-xfs/20230519171829.4108-1-wen.gang.wang@oracle.com/#t)

Reply

[-]

xanadu33@reddit

Was the volume formatted with XFS v4 or XFS v5?

Reply

[-]

xanadu33@reddit

You discovered only now that XFS v4 is deprecated? [https://linuxreviews.org/Prepare\_To\_Re-Format\_If\_You\_Are\_Using\_An\_Older\_XFS\_Filesystem](https://linuxreviews.org/Prepare_To_Re-Format_If_You_Are_Using_An_Older_XFS_Filesystem)

Reply

[-]

ninelore@reddit

Had data corruption from power loss and havent used it since

Reply

[-]

xanadu33@reddit

When was this?

Reply

[-]

ninelore@reddit

Can remember exactly when but it was somewhere between mid 2018 and end of 2020

Reply

[-]

Frosty_Cup9590@reddit

I am using XFS on all my external drives containing movies. It works great on HDD where I can copy and play at the same time without any issue. I have used EXT4 but somehow I found no pauses in XFS. My friend said try it and since then I am very happy.

Reply

[-]

hitsujiTMO@reddit

In general it's because EXT4 is good enough and it's more performant for smaller files. The main thing missing from ext4 that would benefit users is the ability to resize partitions (in particular, inability to change number of inodes). XFS can only grow, but not shrink so it's only marginally better from that perspective. BTRFS will likely become default across the board as it tends to be superior to XFS. The main thing holding it back is that it's not as performant as XFS or EXT4.

Reply

[-]

devonnull@reddit

Does anyone really use BTRFS in production?

Reply

[-]

The-Malix@reddit

>really Why not ?

Reply

[-]

hitsujiTMO@reddit

The ones I know off the top of my head are Valve, Meta, Trip Advisor and Synology.

Reply

[-]

devonnull@reddit

Isn't RAID still broken?

Reply

[-]

Safe-While9946@reddit

RAID in software might be, but almost nobody at an enterprise level uses softraid, as there is always a hardware RAID controller in the box, to handle it.

Reply

[-]

northrupthebandgeek@reddit

I always use softraid if I'm doing RAID, even (especially) in enterprise environments. Hardware RAID controllers have a bad habit of being incompatible with one another, even within the same manufacturer; softraid entirely avoids that.

Reply

[-]

Safe-While9946@reddit

The thing is? Nobody cares about hardware cards being incompatible with each other, because they'll never be concerned about it. Your card dies? Have vendor ship warranty replacement. Server dies? Whole server generally goes. Softraid, while compatible across Linux, can't be seen by anything else as a RAID disk group. I have to say, I enjoy the down votes from speaking... facts about typical enterpise concerns...

Reply

[-]

northrupthebandgeek@reddit

>Your card dies? Have vendor ship warranty replacement. As long as the vendor sends an exact replacement then this is workable, yes. >Server dies? Whole server generally goes. Restoring a large array from backups tends to be a lot slower than just moving the drives between servers. That means more downtime if the server doesn't have a secondary - or even if there's a secondary, a longer window wherein it, too, could fail and result in downtime. >Softraid, while compatible across Linux, can't be seen by anything else as a RAID disk group. That'd only be an issue if I plan on switching operating systems on the server. >I have to say, I enjoy the down votes from speaking... facts about typical enterpise concerns... I didn't downvote you, for what it's worth.

Reply

[-]

Safe-While9946@reddit

> As long as the vendor sends an exact replacement then this is workable, yes. That's how warranty replacements work, yes. > Restoring a large array from backups tends to be a lot slower than just moving the drives between servers. Thats why you dont restore large arrays from backup. Large block devices are on SANs. RAID is for keeping the OS running, in event of a disk failure, and for smaller block volumes locally. > That'd only be an issue if I plan on switching operating systems on the server True. But to that point, incompatible RAID controllers only matter if it's decided to change RAID controllers. Which never happens. You get the controller that was designed for that server. Certified by the OEM, for that platform, running on a distro certified by the vendor. This, again, is my point: soft RAID not being workable on an FS doesn't matter in enterprise deployments: it's rarely used, and only when there isn't another option possible.

Reply

[-]

northrupthebandgeek@reddit

>That's how warranty replacements work, yes. That's far from guaranteed in my experience. >Large block devices are on SANs. Not all orgs can afford SANs or are willing to spend the money on them when the server itself can fit the disk capacity it needs locally. Nor are SANs always appropriate for a given workload's performance needs (especially if latency is a concern). >But to that point, incompatible RAID controllers only matter if it's decided to change RAID controllers. Which never happens. It happens a lot more often than switching from Linux to non-Linux.

Reply

[-]

Safe-While9946@reddit

Ok, SAN attached storage was suitable for all but the most perf critical workloads. Those workloads used local NVME, which we treated, for all intents and purposes, volatile storage. If SAN storage isnt enough for most enterprises... how does the cloud scale so well? It's all network attached storage lol

Reply

[-]

northrupthebandgeek@reddit

>Ok, SAN attached storage was suitable for all but the most perf critical workloads. Those workloads used local NVME, which we treated, for all intents and purposes, volatile storage. "Suitable" ≠ "cost effective". Yeah, if you have an unlimited budget then feel free to go hog-wild, but again: not all enterprises are willing to splurge on a SAN when the server's local drive capacity satisfies their needs (in terms of capacity, reliability, and performance) just fine. >If SAN storage isnt enough for most enterprises... how does the cloud scale so well? It's all network attached storage lol Those cloud providers pump millions upon millions of dollars into R&D to develop custom hardware and software specifically for their hosting infrastructure (including storage), and that money *still* can't buy its way past physics - hence latency and IOPS being sorely lacking on their network-attached block storage offerings. Not to mention that those cloud providers [literally tell you to use software RAID if you want RAID](https://docs.aws.amazon.com/ebs/latest/userguide/raid-config.html) (though this is for RAID 0 specifically, since RAID for reliability doesn't really make much sense in a cloud environment in the first place - whereas RAID 0 can compensate somewhat for the typically-bad performance of cloud block volumes). And back on the topic of on-prem, [Dell makes similar recommendations](https://linux.dell.com/files/whitepapers/Software_RAID_on_Red_Hat_Enterprise_Linux_v6.pdf). The whole point of Sun/Oracle including RAID support in ZFS, on that note, was to avoid the limitations of hardware RAID controllers. Clearly software RAID is more than good enough for the enterprise. The only reason hardware RAID is still common in enterprises is because Windows is still common in enterprises, and Windows' software RAID solutions are notoriously bad. In the Unix/Linux world there's no good reason *not* to go with software RAID. >Now, for non identical RAID controllers being shipped for warranty repair... you need to get a better vendor, like CDW or something then. I don't disagree, but that's something that's often dictated from on high, no matter how strongly those of us in the field object. >But, what do I know? I just architect shit like this on the daily. That makes two of us.

Reply

[-]

hitsujiTMO@reddit

5/6 is, but nothing that isn't solvable by mdadm.

Reply

[-]

devonnull@reddit

Would you elaborate? I've had a hard time understanding if the RAID 5/6 problems are related to hardware or software setups with BTRFS. Side note, I've stuck with MDADM due to portability but use either EXT4 or XFS.

Reply

[-]

uraniumingot@reddit

Iirc btrfs raid issues are with its built-in RAID 5/6 solutions. Anything below that, either sw or hw raid, is fine.

Reply

[-]

devonnull@reddit

Thanks for the clarification, I've been wanting to test it out on a software MD RAID setup underneath but wasn't sure about that. TBH I didn't understand that BTR had a built in RAID implementation, hence my confusion, if that's the case.

Reply

[-]

malikto44@reddit

Synology solves this by using `md-raid`, and putting btrfs on top of that. This works, and will detect bit-rot, but it won't be able to fix it... but at least it does get detected, so something can be done. I have seen some recent stuff about RAID5/RAID6 being workable, and robust enough, however, in general, I rarely see btrfs doing the RAID heavy lifting these days. Instead, it sits on `md-raid`, or ZFS is used. For example, in Ubuntu, even though there are license issues, ZFS is definitely part of the install, and they did a clever way of allowing for an encrypted ZFS root volume. All filesystems have their uses, and good/bad points. There is also a ton of overlap, where ext4 can do just as well as btrfs in a lot of cases.

Reply

[-]

ECrispy@reddit (OP)

I believe FB/Meta does?

Reply

[-]

tinycrazyfish@reddit

Yes, but they don't use any "feature", no checksum, no raid, no snapshot, nothing. Synology uses raid1, afaik. Other than that, almost no one uses btrfs. And no one uses the "extra features"

Reply

[-]

Synthetic451@reddit

>Yes, but they don't use any "feature", no checksum, no raid, no snapshot, nothing. Uhrm, source? Because I am pretty sure Facebook uses features like snapshotting, compression, and RAID mirroring for their build servers and WhatsApp Src: [https://www.youtube.com/watch?v=U7gXR2L05IU](https://www.youtube.com/watch?v=U7gXR2L05IU) Also, if you're not using checksumming (which also means no CoW), no raid, no snapshots, etc., then what is the point of even using btrfs in the first place? Seems silly to actually deploy it and then use none of the features.

Reply

[-]

matt_eskes@reddit

I’m thinking bcachfs will be the standard that btrfs was trying to be, honestly.

Reply

[-]

Synthetic451@reddit

It's still pretty rough around the edges at the moment though. The issues range from simple things like not being able to change the label on an already created volume to more major issues like performance slowdowns on SSDs when deleting large chunks of data with discard enabled. It also doesn't have a stable RAID 5 / 6 implementation yet, just like btrfs, so really at the moment there isn't anything convincing me to move over just yet. If it beats btrfs to RAID 5/6, oh boy, I am jumping ship so fast.

Reply

[-]

matt_eskes@reddit

I'm doing RAID 5 just fine with btrfs... and of course md raid on top of it. But yeah, I know what you mean.

Reply

[-]

Synthetic451@reddit

Yeah, I wanted to use filesystem level RAID rather than mdraid. Hopefully both filesystems will mature and get that working in short order.

Reply

[-]

werpu@reddit

Jepp the development momentum seems to be despite more money being thrown at BTRFS on the BCacheFS side, the development is really strong on it and it matures swiftly. I also thing BTRFS in the long run will fall wayside and BCacheFS will take over the use cases where BTRFS was thought to be used! Somehow BTRFS seems to have dug itself into a complexity hole it does not seem to get out anymore!

Reply

[-]

werpu@reddit

BCacheFS might have a word on this, the development seems to be really speedy! I rather doubht BTRFS is going anywhere once BCacheFS is good enough and that might happen sooner than BTRFS delivers all the missing functionality, but YMMV!

Reply

[-]

Wonderful-Citron-678@reddit

What’s a single missing btrfs feature? Just RAID 5/6 problems?

Reply

[-]

hitsujiTMO@reddit

Maybe, it will be another while before BCacheFS matures enough for any kind of wide adoption.

Reply

[-]

sparky8251@reddit

Been using it since it got mainlined in the kernel and the only problems I've had with it so far are systemd bugs around multidevice mount syntax with it. Been plenty performant, havent lost a bit of data despite being brutal with my restarts (often hard and sudden because of a lack of patience) and its been nice to have access to things like snapshots to boot.

Reply

[-]

werpu@reddit

Yes lets see, they are on a very good trajectory though, while I have the feeling that BTRFs development is slow as molasses. We will see, but I am getting the "vibes" from BTRFS that they did some initial design mistakes or complexity which causes them a hard time now to get any new features in! But the more stable COW filesystems the better!

Reply

[-]

tajetaje@reddit

Even windows is moving towards a CoW file system to replace/supplement NTFS

Reply

[-]

malikto44@reddit

BCacheFS has a lot of cool things. Once they get scrubbing, send/receive, and other features that btrfs and ZFS have, it will definitely be a solid alternative, and it seems that development is constantly going on. I'm hoping it matures and RHEL adopts it, so RHEL has at least one checksumming filesystem for a defense against bit rot. One nice feature is BCacheFS's encryption, which provides authenticated encryption and can detect tampering. Overall, it is definitely something nice for an up and coming enterprise filesystem.

Reply

[-]

6e1a08c8047143c6869@reddit

> The main thing missing from ext4 that would benefit users is the ability to resize partitions (in particular, inability to change number of inodes). Can't you just do that with `resize2fs`?

Reply

[-]

hitsujiTMO@reddit

That will resize the boundaries of the partition, but without being able to adjust the inodes you're not really adjusting anything as you may still run out of inodes before you come close to filling the extended space.

Reply

[-]

6e1a08c8047143c6869@reddit

To be pedantic, it will only resize the filesystem, not the partition. And I don't think that's true: # dd if=/dev/zero of=/tmp/blockfile bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,29674 s, 828 MB/s # losetup /dev/loop0 /tmp/blockfile # parted /dev/loop0 mklabel gpt Information: You may need to update /etc/fstab. # parted /dev/loop0 mkpart testpartition ext4 1 512M Information: You may need to update /etc/fstab. # mkfs.ext4 /dev/loop0p1 mke2fs 1.47.1 (20-May-2024) Discarding device blocks: done Creating filesystem with 498688 1k blocks and 124440 inodes Filesystem UUID: a090e219-defd-4a6c-aae8-07e0f5bd9588 Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done # mount /dev/loop0p1 /mnt # df -i /mnt/ Filesystem Inodes IUsed IFree IUse% Mounted on /dev/loop0p1 124440 12 124428 1% /mnt # umount /mnt # parted /dev/loop0 resizepart 1 100% Information: You may need to update /etc/fstab. # resize2fs -f /dev/loop0p1 1000M resize2fs 1.47.1 (20-May-2024) Resizing the filesystem on /dev/loop0p1 to 1024000 (1k) blocks. The filesystem on /dev/loop0p1 is now 1024000 (1k) blocks long. # mount /dev/loop0p1 /mnt # df -i /mnt Filesystem Inodes IUsed IFree IUse% Mounted on /dev/loop0p1 255000 12 254988 1% /mnt So it seems like the number of inodes is increased.

Reply

[-]

Rezrex91@reddit

I didn't measure or run benchmarks but to me XFS seems to be more performant than ext4. I used both ext4 and now XFS on the same SATA3 SSD as my root filesystem for Gentoo, and both file access latency and file operations seem to be better on XFS for small and large files too.

Reply

[-]

hitsujiTMO@reddit

Data in the wild suggests XFS is more performant for larger files, while EXT4 is more performant for smaller files. I don't know if SATA3 would be a bottleneck in any testing in this case.

Reply

[-]

ECrispy@reddit (OP)

XFS is far more scalable and performant. This may not matter for desktop users though.

Reply

[-]

hitsujiTMO@reddit

I agree, it's just that distros seem to be adopting BTRFS over XFS now that it has matured enough to be used as default FS.

Reply

[-]

cjcox4@reddit

As you mentioned, still popular on RHEL-like systems and I believe still the default there. Red Hat put a lot of work into shoring up XFS some years ago. The idea being, to make xfs as mature and reliable as ext4. I can break anyone's btrfs using legal and valid btrfs commands, the point of making your systems unbootable. Just saying. Not talking about deliberate commands to break it, but commands that, well, probably should work. But most people don't use "everything", and so it's likely you'll never have this happen. That is, things like btrfs still have some maturing left to do, especially if you consider there's still a lot of activity on "features"... the "shoring up" will come later. And of course, there's a myriad of outside drivers that also impact their development. Layered elements vs. "all in one" approaches, and the conflicts, or lack of understanding of each other, etc. And then, there's the "golden child" of the "all in ones", ZFS. As for me, on the enterprise level, because of "features", we started migrating away from the default XFS on our RHEL-like infrastructure and using ext4. "Features" in this case can be as simple as "it performs faster in this case, therefore use it." Personally, I'm fine with either and we're still mixed today. Infrastructure wise, it's enterprise, so the concept of things going down "hard" would be an extremely, extremely rare event (like winning the lottery). The few case I've seen of "that" though, I haven't lost anything, but honestly, it's a crap shoot.... so I'm sure there are horror stories out there. From my perspective, create me a relatively performant filesystem that can grow and shrink on the fly (mounted and online) while enabling me to return pooled storage back (to the point of pulling physical storage and replacing), and I'm your friend for life. Give me encryption and compression at the file level, not merely at the block level. Give me file versioning at the file level. Etc, etc...

Reply

[-]

vagrantprodigy07@reddit

>I can break anyone's btrfs using legal and valid btrfs commands, the point of making your systems unbootable. Just saying. Not talking about deliberate commands to break it, but commands that, well, probably should work. Just do a few hard power downs, btrfs will break itself often enough.

Reply

[-]

turdas@reddit

I've done more than a few hard power downs on my desktop after unrecoverable graphics driver crashes, and am yet to have an issue with btrfs.

Reply

[-]

Impressive-Care-5914@reddit

Most likely there was little to no I/O going on at the time. Compile something large and shut the system down while the drives are busy and you'll see how fragile btrfs can be.

Reply

[-]

turdas@reddit

Have you had that happen to you, or is that something you heard happening to someone's friend on HackerNews 10 years ago? There's no reason btrfs would be any more susceptible to corruption in such a situation than a traditional journaling filesystem. In fact, it's probably *less* susceptible to corruption in such a situation than something like ext4.

Reply

[-]

Impressive-Care-5914@reddit

I tested several filesystems simulating loss of power and found that ext4 was the hardest to corrupt and btrfs fared poorly (out of popular filesystems). I recall f2fs did well as long as there was no other corruption. I also tested them to see how well they could recover from on-disk corruption. The dm-flakey target is good for testing this.

Reply

[-]

turdas@reddit

And how did you check whether there was corruption? Ext4 and f2fs do not do checksumming so they would naturally not be able to detect most types of data corruption, while btrfs can. Just because the filesystem lets you boot and doesn't report any errors doesn't mean the power loss didn't cause corruption.

Reply

[-]

Impressive-Care-5914@reddit

See the last paragraph. I pointed out that ext4 was worse than btrfs at detecting minor corruption. However power loss didn't cause any corruption in files for ext4 (I don't remember if it did for f2fs), but using the flakey device mapper target to simulate on-drive corruption showed that ext4 was better at surviving massive corruption but btrfs was better at noticing minor corruption, but worse at surviving massive corruption.

Reply

[-]

turdas@reddit

Fair enough. That last paragraph wasn't there yet when I wrote my reply. I would still point out that tests like multiple contiguous sectors getting completely overwritten don't exactly sound like something that would happen in the real world to me. In my experience btrfs quickly drops the filesystem to read only mode at the first sign of something bad happening.

Reply

[-]

Impressive-Care-5914@reddit

Multiple contiguous sectors being damaged happens more often as a result of memory errors or on older SSDs when an entire flash block fails. All filesystems will try to drop into read-only mode but most of what they read will be cached, so no filesystem, btrfs, ext4, bcachefs, ntfs, zfs or any other will realize what is happening until it's too late and severe damage has already been done. Then the only question is how well they can recover.

Reply

[-]

pnutjam@reddit

100% same I use btrfs for my OS and home so I can do snapshots for updates and backups (opensuse). I have a big data drive that runs XFS and I backup that drive to a btrfs drive so I can grab a snapshot after every backup, which gives me immutable backups and protects me from ransomware.

Reply

[-]

Impressive-Care-5914@reddit

It's not only sudden power loss that btrfs handles poorly. I have found that severe corruption on the block device level completely kills btrfs in a way that doesn't really happen to other filesystems. In my experience, severe corruption of that kind will make btrfs unrecoverable. Ext4 will lose some files and some metadata may be messed up, but it will often be able to recover itself to full internal consistency. Surprisingly FAT handles this the best in terms of being able to recover to an internally consistent state, but the actual contents of the filesystem become utterly nonsensical.

Reply

[-]

cjcox4@reddit

And it's not to say it's all bad, but typical and things to work on. Like any other filesystem that's been added. (noting that hard power downs are some of the most damaging things you can do regardless of filesystem)

Reply

[-]

vagrantprodigy07@reddit

The difference is that most file systems can recover from them, BTRFS not so much. I've had a few data corruption events with XFS, and always recovered the data.

Reply

[-]

cjcox4@reddit

Reminds me of reiserfs. When it was new and fresh and different, we didn't care, because we had an growable online filesystem. But....

Reply

[-]

ezoe@reddit

> things like btrfs still have some maturing left to do It's been 15 years since btrfs was mainlined to Linux kernel. How could that be possible? If 15 years not enought to be matured, it never will.

Reply

[-]

KingStannis2020@reddit

It seems genuinely possible that bcachefs will reach a mature state sooner.

Reply

[-]

cjcox4@reddit

Nice idea, but no. Btrfs continues to evolve. Just because something gets added a long time ago does not mean it's complete. So, I wouldn't measure btrfs by "time of entry". It's actually had some radical changes even 10 years on since entry. Some of those changes years after inclusion were "total break" changes. Others were "total break" in this situation or that... my point, there's been quite a bit.

Reply

[-]

malikto44@reddit

Meta did a lot of work on btrfs, and there are a few changes that are coming, like fscrypt support, which will allow file encryption. I would say btrfs does evolve... but so does ZFS, where ZFS's deduplication is getting some changes. As for being afraid of data loss, Synology has used btrfs for over a decade. Recently, Synology made btrfs the default file system for all their NAS offerings, even the single drive model. If there were issues with data loss, Synology would be screamed at from everywhere. Ironically, Synology has a modified btrfs, with an entire set of features called locker/"lock & roll" which add date based object locking (basically a modified chattr +i or +a unlocked after a period of time.) Overall, I trust btrfs for my general purpose filesystem. This doesn't say that XFS isn't useful. In the RHEL universe, you pretty much have that or ext4, so if you are doing RAID, you will need to have the checksumming to prevent bit-rot at the `dm-integrity` level. XFS is quite useful if you are doing a MinIO cluster. Since MinIO handles RAID across drives and redundancy across machines, there is no need for any machine based RAID like ZFS or `md-raid`, thus making volumes that have XFS on them the best choice for performance for that application.

Reply

[-]

Due_Bass7191@reddit

it is default. I've not noticed any issues with xfs.

Reply

[-]

Zharaqumi@reddit

Same. I've been using xfs for more than 8 years. No issues so far.

Reply

[-]

CecilXIII@reddit

Can you elaborate a bit more on the breaking btrfs part? I'm curious

Reply

[-]

cjcox4@reddit

btrfs supports a type of "raid", and I'm not going to touch on the more recent raid 5, etc., but just on mirroring. If you play enough with that, going backwards and forwards, it will break.

Reply

[-]

postmodest@reddit

One big one is that some backup tools can treat Ext4 images as a tar archive but can't read xfs images without mounting the whole thing.

Reply

[-]

ECrispy@reddit (OP)

do you mean e2image for ext4? I've never really found much mention of it beyond some reddit posts. Does anything like it exist for XFS?

Reply

[-]

dorel@reddit

How do you deduplicate files on XFS?

Reply

[-]

ECrispy@reddit (OP)

sort of like btrfs, you use reflink to copy files which makes them CoW, and then use duperemove in xfs.

Reply

[-]

dorel@reddit

I already have a bunch of files. What's next? What do I run?

Reply

[-]

ECrispy@reddit (OP)

look up copy with reflinks, that will make a CoW copy

Reply

[-]

dorel@reddit

You're not getting my message. Is there a program that can do this for me? I've used bees for BTRFS. Now what about XFS?

Reply

[-]

whosdr@reddit

So it's file-level CoW, rather than block-level?

Reply

[-]

ECrispy@reddit (OP)

its block level. I'm no expert on it. I believe it doesnt work for in use files. If you google you find a few resources. e.g this video - [https://www.youtube.com/watch?v=wG8FUvSGROw](https://www.youtube.com/watch?v=wG8FUvSGROw)

Reply

[-]

whosdr@reddit

I can't watch the video at the moment as my headset's currently recharging. But scrolling through and reading the bullet points suggests it's file-level still.

Reply

[-]

ECrispy@reddit (OP)

you may well be correct. this is also a good read - [https://lwn.net/Articles/747633/](https://lwn.net/Articles/747633/)

Reply

[-]

rbrockway@reddit

I've always thought it was a shame that [NilFS](https://en.wikipedia.org/wiki/NILFS) wasn't more popular.

Reply

[-]

rbrockway@reddit

XFS has better quota code, project quotas and xfsdump/xfsrestore. I find its many features very useful even on workstations and laptops.

Reply

[-]

ut316ab@reddit

I tried XFS a few years ago but moved off of it because some game I was trying to play specifically didn't work well with XFS, I forget the game name now, I think it might have been Civ 5? I don't remember.

Reply

[-]

ECrispy@reddit (OP)

yes there are games that do this. Steam is notorious for this. And its because their devs are clueless, prob compiled the game in 32 bit etc. Anyway, the end result is you are a gamer, stick to ext4.

Reply

[-]

ut316ab@reddit

That is the thing though right? MOST Distros are just General Purpose, so they need to be able to do most things. If XFS is bad for gaming, that would make it bad as a default FS for a General Purpose Distro.

Reply

[-]

ECrispy@reddit (OP)

which is why it probably isn't for desktop distros. But for someone who's a non gamer like me, does it not make more sense?

Reply

[-]

northrupthebandgeek@reddit

XFS was my go-to for both Slackware and openSUSE for a long time. Then openSUSE started leaning on btrfs for things like Snapper, so I switched the root FS to btrfs while keeping `/home` on XFS (and Snapper has saved my bacon multiple times). Nowadays, I've gravitated toward openSUSE Aeon, which is very opinionated by default when it comes to btrfs, so I generally just stick to btrfs for everything on those installs. If I do deviate from that (e.g. with another distro, or after doing the necessary surgery to make Aeon cooperate with `/home` living outside of the btrfs partition), I opt for ext4 for `/home` to take advantage of casefolding support (XFS allegedly supports casefolding, too, but ext4 is the direction Valve went for SteamOS so I might as well follow that lead).

Reply

[-]

ClubPuzzleheaded8514@reddit

Smart! Are you satisfied with the combo btrfs root/ xfs home? Do you see any improvements?

Reply

[-]

Asleep_Detective3274@reddit

XFS is my go to filesystem, I recently tried pretty much all of them, EXT4, BTRFS, JFS, F2FS, NILFS, BCACHEFS, and XFS was the fastest for typical scenarios like transferring video files and so on, I also performed crash tests where I would be watching a video and writing to a text file when I pressed the reboot button on my PC, and XFS had no issues, it booted up fine, and the video was fine and the test file was fine too, besides missing a few words that hadn't been saved to the file, reflinks is also very handy, I've made a few snapshots of my /home directory where I've needed to look at a config file from one of the older snapshots.

Reply

[-]

SeriousPlankton2000@reddit

We like XFS is a boring, quite reliable (AFAIK) fs - but we use ext because it's even more boring. I'd like btrfs, but unfortunately btrfsck should better be a symlink to mkfs.ext$n

Reply

[-]

involution@reddit

I love how ext#n does snapshots honestly

Reply

[-]

SeriousPlankton2000@reddit

For btrfs I need a snapshot of before the fs develops incurable errors.-( It's a shame, btr is a good fs, but because they insist on "We know the parent ID should bs A, the value says B and therefore we refuse to fix it, we don't even let you remove that directory", I can't really use it.

Reply

[-]

involution@reddit

it's interesting that you won't use btrfs because it won't solve bit rot somehow magically in snapshots, yet you suggest "we use" ie. you, use ext4, and suggest it's basically the same. As to your other ramblings, I have no fucking idea what you're even on about

Reply

[-]

SeriousPlankton2000@reddit

I don't use it because it is the only fs that accumulates bad values in the **metadata** that shouldn't happen in the first place because of the journal. I don't use it because it **refuses to fix the metadata**. Best "hope" is renaming the affected directory and ignoring it.

Reply

[-]

involution@reddit

If only btrfs could do some kinda scrub that would fix such issues

Reply

[-]

SeriousPlankton2000@reddit

It can't and it actively refuses to fix this issue because it's in two distinct parts of the metadata that became inconsistent because only one part was written correctly.

Reply

[-]

Responsible-Lock7642@reddit

I don't know for other use cases, but for gaming, Ext4 will always be recommended, or at least as long as it is the only file system that supports case fold, this feature is used by Protón and Wine, The fact that your file system does not support it, no matter how fast it is, you will see regressions when running games through Wine and Proton I personally use Btrfs on my Linux installation and Ext4 on the disk I have my games, I never saw it necessary to use or test other file systems

Reply

[-]

sparky8251@reddit

Weird... been gaming on Linux for almost 8 years now and almost all of that has been with a non-ext4 FS such as BTRFS, ZFS, and now most recently BcacheFS. Never had an issue...

Reply

[-]

Responsible-Lock7642@reddit

It's not like it's causing you a problem that you can't run a game or something, you're just not going to get the most out of your disk in Gaming, If you use a fast enough SSD or a NVMe you will not notice the difference, but when using a HDD or a not so fast SSD the performance regression is very noticeable, especially when loading shaders or textures, There's one of the reasons the Steam Deck uses Ext4 as the default file system.

Reply

[-]

sparky8251@reddit

Ah, thats probably why then. Been using the premium grade SSDs and NVMe drives ever since they came out. That would be why I've not noticed a thing :)

Reply

[-]

whosdr@reddit

I just run different filesystems for different use-cases. Root is btrfs, home is ext4, and a separate game partition is also ext4.

Reply

[-]

-reserved-@reddit

>supposedly XFS doesn't handle hw failures. Even on this I found no consensus - some people say its risky and can corrupt with no recovery, others say even with a forced shutdown its safe. I'm not sure if its any less robust than ext4/btrfs? Is this actually a concern these days? XFS is notoriously difficult to recover deleted or lost data from. There are apparently tools that claim to work but most of them are commercial tools that require payment. Depending on your setup you can compensate for this by using RAID and UPS to keep the system live even with hardware or power failure. This could even be an advantage if you're worried about privacy but it could be a concern for some users.

Reply

[-]

ahferroin7@reddit

Most of it comes down to people not caring about the filesystem they use until it causes them issues, and ext4 working _well enough_ for normal usage, and ext* in general being the default is a matter of history (ext2 beat out xiafs for very significant engineering reasons, ext3 then beat XFS into the kernel and was trivial to add support for in existing installer code that already supported ext2 as compared to XFS needing additional tooling to be added). In general though, XFS has only a handful of limitations these days: - As you mentioned, XFS volumes cannot be shrunk. This is, indeed, not a common use case for most people, but it’s something people tend to _really_ hate when they actually need to care about it, so it’s usually what people quote as the reason that they don’t use XFS. The silliest part is that this is also the _easiest limitation to work around_, just recreate the volume at the desired size and restore an up to date backup (or, if you’re the crazy type who doesn’t do regular backups, _create a backup_, recreate the volume, then restore the backup). - It mandates the use of journaling. This sounds like a silly limitation, but ext4 can very specifically be run without a journal, which can be beneficial in some unusual situations because it means you still get the benefits of stuff like extent-based allocation, but you also cut out a large majority of the metadata handling overhead inherent in using a journaled filesystem. I actually personally use ext4 like this in a couple of rare situations where I know performance truly does matter more than data safety. - XFS is optimized for consistent performance over the lifetime of the filesystem. More specifically, XFS will get about the same performance for a given volume-size, file count, and amount of data no matter how organized/disorganized the filesystem is. This makes XFS great for long-lived volumes where performance characteristics matter, but it also makes it a bit less performant in ‘optimal’ file arrangements than exty4, which instead implicitly assumes the volume will be optimally organized. Given this, ext4 can be a tiny bit better for things like storage of very large numbers of files in WORM workloads where all the files get put into place at the same time. - XFS volumes can only be resized on-line. IOW, you can’t resize an XFS volume without it being mounted. This essentially never matters, but it is a limitation.

Reply

[-]

ECrispy@reddit (OP)

Thanks for the details. About #3 - while I'm fairly certain this kind of thing won't be measurable outside synthetic benchmarks, how many files are we talking about - millions? or does % of disk full matters. Sounds like ext4 like most other fd will degrade with fragmentation but XFS doesn't? Also you haven't said anything about XFS being more brittle to hw failure, e.g. sudden power loss, while many others claim. Does this mean its no longer the case?

Reply

[-]

ahferroin7@reddit

> About #3 - while I'm fairly certain this kind of thing won't be measurable outside synthetic benchmarks, how many files are we talking about - millions? or does % of disk full matters. Sounds like ext4 like most other fd will degrade with fragmentation but XFS doesn't? The percentage of full disk space, number of files, and average size of the files all matter. And it is generally relatively small in terms of difference, but even small percentages can matter when you’re dealing with very large numbers. Note that this is not to say that XFS _doesn’t_ degrade in performance with high levels of fragmentation, but if you ignore the implications of the underlying storage stack (that is, stuff like seek latency and IOPS limits), XFS itself is affected by it a bit less than ext4. > Also you haven't said anything about XFS being more brittle to hw failure, e.g. sudden power loss, while many others claim. Does this mean its no longer the case? AFAIK, modern XFS is no worse in this respect than ext4, and in my experience it’s actually a bit better than ext4, though this may have more to do with the fact that XFS fails pretty explicitly and cleanly in a number of cases where ext4 by default just flags the volume to be checked and continues on as if nothing is wrong. _However_, XFS gives up a bit more readily in the face of issues than ext4 does, possibly because it’s designed primarily for enterprise usage, and therefore it’s a reasonable assumption that the user can always rebuild the volume from a backup. Note that very early versions of XFS for Linux did actually have some recovery issues after a power loss, but the same is generally true of _any_ new filesystem.

Reply

[-]

natermer@reddit

Ext4 is the most fault tolerant file system for Linux. So when dealing with random shitty hardware and power losses Ext4 is the least likely to eat your data. Btrfs is far less robust, but it is more featurefull and allows distro designers to easy fool around with features that use snapshots and whatnot. It is good for people that care more about having lots of features then overal performance and data safety. XFS is just like a sometimes-barely-faster version of Ext4.. a journalling file system that is slightly less robust. It works. I use either xfs or ext4 interchangeably.

Reply

[-]

zeddy360@reddit

was using ext4 for many years but on my current system i chose btrfs because: - snapshots, support for them in timeshift and preconfigured automation of those in pacman on my distribution - it has a well working windows driver. there are very rare cases where i want to play VR on windows because it (unfortunately) does still work better on windows. but i don't want to waste huge amounts of disk space to those vr games then. so i just mount my games drive on windows with that driver. other than that, i personally don't really care about the file system vOv if XFS or other file systems can do this stuff as well: cool but i don't see me switching because btrfs always worked perfectly fine for me. i neither see me shrinking my partitions but if i one day have to, i now know that XFS can't do that... so thanks for the info :D

Reply

[-]

Anonymo@reddit

Because ZFS exists.

Reply

[-]

lustriousParsnip639@reddit

When will it be merged?

Reply

[-]

Anonymo@reddit

Not anytime soon, but it's usable out of kernel. Just have to make sure you don't upgrade the kernels before ZFS supports them.

Reply

[-]

lustriousParsnip639@reddit

Any idea what the main holdup might be?

Reply

[-]

Anonymo@reddit

The license is incompatible with GPL from Linux.

Reply

[-]

mufasathetiger@reddit

its a well designed filesystem and robust but its not good enough to outshine ext4 (the default).You got to be much more capable than that to take a part of the market. For example: btrfs brings a whole new level to the game that makes acceptable disrupting the classic workflow.

Reply

[-]

bobbie434343@reddit

Still using XFS for my /home partition as it was the default when I installed openSUSE Tumbleweed on my laptop 5.5 years ago (/ is btrfs). Never had an issue with XFS.

Reply

[-]

themightyug@reddit

I've been using XFS filesystems on my machines for years without issue, including raspberry pi micro servers, and my daily driver desktop

Reply

[-]

daelikon@reddit

Same for me. It comes with a defrag utility that no one seems to mention either. I started trying BTRFS about a year ago in some systems. In my experience it is very resilient. I have never used ext3/4.

Reply

[-]

darknekolux@reddit

Xfs had the bad habit of losing your opened files during unexpected reboots. Also the main driver behind xfs was SGI which is now long gone.

Reply

[-]

left_shoulder_demon@reddit

SGI XFS was a completely different beast than modern XFS. SGI XFS was designed around SGI hardware, which had emergency power for 2.5 seconds and a designated RAM area that would be preserved during reboots, so the journal would seldom be written to disk. The first iterations of XFS on Linux then explicitly synchronized the journal, and it was really slow, to the point where I had a script to rename directories and delete their contents in the background so I could continue working.

Reply

[-]

Zathrus1@reddit

Tell me you know nothing about XFS without telling me you know nothing about XFS. Red Hat took over XFS development over 15 years ago and it’s been the default FS for just over a decade (RHEL 7, which goes to extended support in all of 13 days and was released 10 years and 8 days ago).

Reply

[-]

darknekolux@reddit

I'll admit it's been a while since I stopped caring. losing opened files was a thing thought...

Reply

[-]

Zathrus1@reddit

It was, but I’m also guessing that it was over 15 years ago, probably back when SGI were still the maintainers. It’s evolved since then. If it was still doing that, RH would be in a world of hurt.

Reply

[-]

ECrispy@reddit (OP)

had or still has? thats my main question - is it considered any less safe than ext4/btrfs, there are plenty of horror stories on everrything. also, its now backed by RHEL, by far the biggest Linux company and isn't going anywhere.

Reply

[-]

BenL90@reddit

But RHEL also is process pushing stratis, well for different purpose. But the strange things is, they also thinking putting it into consumer devices... 😂 Let us wait and see. Well xfs will stay, but I still thing it need more time either they go with stratis or stay with xfs.

Reply

[-]

matt_eskes@reddit

Stratis is still XFS, just with a different volume manager

Reply

[-]

Mister_Magister@reddit

because what's the point of xfs. I am advanced linux user and yet i never bothered to find out. ext4 works fine if not ext4 then btrfs/zfs altho opensuse default is btrfs and xfs combo so there's that

Reply

[-]

left_shoulder_demon@reddit

Largely historical reasons. When XFS came out, ext2/ext3 could not handle large volumes, so if you had massive amounts of data, you were kind of forced to use XFS -- and Red Hat was pushing it hard for their enterprise customers, while the home users provided testing.

Reply

[-]

Sol33t303@reddit

XFS has more features then EXT4 (as the post said, nowadays it has stuff like COW), but doesn't historically have the issues of BTRFS, and doesn't have the big RAM requirements of ZFS (and it's not a filesystem that relies on an out of kernel module and is controlled by Oracle). I'd basically consider XFS a better EXT4 almost, just with the problem of not being able to be shrunk.

Reply

[-]

sparky8251@reddit

ZFS doesnt have large RAM requirements if you dont plan to use dedup. That linux tools cant report the ARC is more about ZFS being out of tree than it being used RAM that your programs cant claim if needed.

Reply

[-]

Sol33t303@reddit

And using L2ARC, I had a VM host that had 24 GB of RAM with a 2 TB HDD and a 500 GB NVME for cache. VM had 16 GB RAM allocated. During heavy IO the VM would get OOM killed, moved it over to to an EXT drive, problem went away, move it back on to the ZFS drive, problem came back. I also confirmed this by watching the host over an SSH connection.

Reply

[-]

sparky8251@reddit

That sounds... fun. Wonder if OOM killer also sometimes work based on memory latency and since even nvme drives can be far too slow compared to RAM thats why it happened? ZFS has lots of weird papercut edges on it due to not being in the main kernel tree... I like it, I really do... But I want an in tree replacement even more. Cant wait for bcachefs to mature more as a result since btrfs has been a massive disappointment in that regard.

Reply

[-]

Jeff-J@reddit

I used to use XFS. Never had a problem with it. I haven't used it in a while. I think I stopped using it years ago on laptops. Currently, I have only laptops. I think there was something about suspending or hibernating that was an issue on them. I hopped over to the Gentoo handbook to see if I could confirm this. It recommends XFS for general use especially with Gentoo.

Reply

[-]

ECrispy@reddit (OP)

so what are you saying - XFS is not recommended for laptops on Linux, but is for Gentoo? or are those older issues fixed?

Reply

[-]

Jeff-J@reddit

That is not what I am saying. I have been using Gentoo since 2001. When I set up my new laptop in 2007, it was suggested to not use XFS on laptops. I don't remember if it was in the handbook or forums. I still used it in desktops and workstations. Since XFS was brought up, I checked the current handbook. It suggests using XFS for general use. There are specific positive attributes to the way it works that lend themselves to benefiting the workflow of Gentoo. Check the Gentoo handbook in the choosing a filesystem section if you want the specific reason.

Reply

[-]

S48GS@reddit

For HDD - EXT4 because you actually can restore data when HDD lost power or some low level error happened or you format it and start writing and then remember you had not saved data before. For SSD - btrfs - it just work, no on care. (and there no point to worry about power loss on ssd because it work differently compare to hdd and will safe "packets in fly" even if physically disconnect ssd during copy) (and if ssd breaks, actually breaks like controller stops working - there absolutely no way to restore data - so does not matter what fs)

Reply

[-]

ECrispy@reddit (OP)

How is ext4 any safer on hdd?

Reply

[-]

forbjok@reddit

I used XFS for some time back in 2004-2006 or so, and the only reason I switched away from it was HDD noise. Today, with drives mostly being SSD I'm thinking it might be worth trying it out again, as SSDs don't make any noise anyway.

Reply

[-]

audioen@reddit

I dunno, seems worse than btrfs and if the only argument is performance, well, I run multi-terabyte SSDs on top of hardware raid with write cache. These things are *fast* to the point that I can't saturate the drives, everything is either CPU or network bound. I still have the same filesystems I created in 2010 running, with hourly backups taken via btrfs send/receive, and distributed to multiple locations. XFS may be great, but I doubt it is even as good as what I have today. Just recently, I migrated btrfs online from one raid array to another, by going to server room, plugging in new disks, creating the volume and then just adding it into the volume and deleting the old one. Sure, the thing churned for multiple hours as it migrated, but in the end, it was done and nobody saw any downtime, at most degraded performance. I do have to shrink filesystems sometimes as well. A lot of the time, there is no data at all in the portion that I remove, so it is pretty fast to just register the new size. Why can't filesystems migrate data? I guess it is the virtual-to-physical chunk mapping in btrfs that allows for this. If you move the chunk physically, you only have to change this mapping, and so it can be done chunk by chunk. No doubt these various capabilities comes with costs as well, but I don't see them. The biggest annoyance I ever saw with btrfs was with systemd's journald, actually. It defaults to turning CoW off on the journal files which defeats my incremental backups. It is literally the only thing anywhere that attempts to use the flag automatically for anything, and causes the fact that journal files are not part of my incremental backup stream, which is unhelpful, surprising and annoying.

Reply

[-]

schneensch@reddit

Even though XFS is technically superior to ext4, my guess is that the differences were never big enough to warrant a change of default filesystems for many distros. Changing filesystems can cause a bunch of different issues for distros, because then you have 2 different file systems in use. Also you need to re-test and validate a bunch of stuff again. So I guess it was never really worth it until BTRFS got stable enough.

Reply

[-]

DMG_95@reddit

The analysis you've conducted on XFS is quite comprehensive and accurate in many aspects. Let me address the concerns you've mentioned and offer some additional insights: 1. **Popularity**: It's true that XFS isn't as popular in home desktop environments as ext4 or even btrfs. This is partly because ext4 is the default file system in most Linux distributions, making it more accessible and familiar to users. Additionally, perceptions of stability and community support play a crucial role in file system choice. 2. **Performance**: XFS has proven to be very efficient in terms of performance, especially in parallel workloads and with SSDs. Concerns about CPU-intensive metadata updates have been addressed in recent versions, further enhancing its appeal for desktop use. 3. **Snapshots and advanced features**: While XFS doesn't natively offer copy-on-write (CoW) features like btrfs or ZFS, it supports hard links and allows for snapshots using third-party tools such as `snapper` or `timeshift`. While not as advanced as CoW, reflink-based snapshots can meet many home user needs. 4. **Stability and reliability**: XFS is widely recognized for its stability and reliability in enterprise environments, handling large data volumes robustly. Regarding hardware failures, any file system is at risk under severe failures, but modern implementations of XFS have improved in terms of fault tolerance and recovery. 5. **Limitations**: It's true that XFS doesn't support online volume resizing, which can be inconvenient for certain advanced use cases. However, as you mentioned, this is rarely a requirement for most home users. In summary, XFS offers a robust set of features and excellent performance that make it suitable for many use cases, including home desktop environments. However, its broader adoption is limited by the prevalence of default alternatives like ext4 and the lack of integrated advanced features such as CoW and sophisticated snapshot capabilities. For users seeking stability and good performance without needing the advanced features of btrfs or ZFS, XFS remains a very viable option.

Reply

[-]

Many-Ad5501@reddit

Better question would be why ppl not using zfs?

Reply

[-]

Anonymo@reddit

Licensing is incompatible with the kernel, so it can break or the versions can run late at times vs kernel releases.

Reply

[-]

sparky8251@reddit

ARC is also not properly reported in basically all Linux memory viewing tools making it a PITA to know if you have available RAM or not.

Reply

[-]

Synthetic451@reddit

Because it isn't in the kernel tree. Personally, I am using it for my Arch-based NAS, but it is annoying as heck to be limited to linux-lts simply because the OpenZFS project can't keep up with the latest kernels. Also, not that this is a disadvantage compared to XFS, but I am not a fan of how rollbacks work in ZFS, where you have to delete all the intermediary snapshots.

Reply

[-]

EchoGecko795@reddit

My understanding that silent disk failure is one of the big reasons why it went into decline and systems like ZFS and BTRFS started to replace it, add in that the biggest feature raw speed is a non issue now with SSDs and even high speed HHDs out there.

Reply

[-]

Mr_Henry_Yau@reddit

Some people don't even know XFS exists in the first place.

Reply

[-]

Maiksu619@reddit

Noob here. However, I came across a recent [video that DJ Ware](https://youtu.be/AhjL1SHku7M?si=UZV13zy6xnPoCf1O) did a couple months ago comparing BCACHEFS, BTRFS, EXT4, F2FS, and XFS. Overall, it seems that EXT4 and XFS were above the rest in most of the tests and they seemed to perform very similarly. Both of them were slightly better than one another in different tests, but about 50/50. In the overall mean of the tests, XFS tested very minimally better at the lower end tasks and EXT4 tested very minimally better at the higher end tasks. Overall though, very interesting comparison. I’ve heard a lot about BTRFS lately and wanted to learn more about the hype. At the end of the day, I don’t see any major performance jump that would make me want to switch. Plus, as others above me have mentioned, the inability to shrink a volume is a dealbreaker for me. Lastly, I’m a noob still and very much learning. Just found the topic interesting.

Reply

[-]

MonkeeSage@reddit

> All of this comes without the usual cost of CoW I think this is wrong. As far as I understand cp --reflink with xfs doesn't provide any cost savings over the built in LVM CoW or btrfs CoW features for example. And tools like deduperemove also have to scan and hash blocks on the filesystem and then submit the duplicate blocks to the kernel for removal via ioctl_FIDEDUPERANGE, so there's no cost saving there either afaik.

Reply

[-]

returnofblank@reddit

XFS doesn't offer filesystem compression, and that's really the one feature I want

Reply

[-]

InsensitiveClown@reddit

I've been using XFS since, well, since SGI existed really, and you had to use the SGI patches to patch kernel 2.4 series. It depends on the application really. SGI XFS is optimal for large sequences of large files with approximately identical size, such as, for example, sequences of 32bpc LogLUV encoded TIFF files. It's hardly surprising since SGI was in the business of computer graphics for audiovisual production. I still use it this day and I never ran into any issues whatsoever. My applications are image processing, again, large sequences of approximately identical files, in this case, CR2, CRW RAW files from my digital cameras, or TIFF files from scans. Some audiovisual/CG work also, mostly EXR sequences which are then h265 encoded for distribution. For general use, i use EXT4, and previously i used to use ReiserFS for large amounts of small files (e.g. logs, content of /var and so on), but mostly these days it's just EXT4 for general use and XFS for anything where throughput is critical. Data is stored on a couple of NVME SSDs, so, the elevator is **noop**, lukewarm storage is in HDDs, with bfq multi-queue. Cold storage is :ahem: external HDDs. It probably should be LTO but...

Reply

[-]

Dave_A480@reddit

XFS was the default for RHEL for quite some time .... So it did get used..... Most people don't care between XFS and ext4, for regular usage..... At the point where you are thinking about zfs or similar you aren't in the most people category....

Reply

[-]

JockstrapCummies@reddit

XFS was made for enterprise hardware as you say due to its pedigree. This begins to create problems when you start using unreliable and cheap consumer hardware that don't provide the same assumptions as quality hardware. I have, on multiple times now, have XFS partitions rendered completely unsalvageable due to sudden unmounts/hard resets on garbage, outdated hardware. The horrifying `superblock read failed` error that cannot be fixed except restoring from backup.

Reply

[-]

Sabinno@reddit

Shrinking volumes is a pretty dang common use case. Dual booting is not unusual these days, especially in the software development space, which, you know, there are close to 30 million. Whenever I deploy XFS vols, I'm insanely conservative about disk usage and only provision like 1 GB for /home/ for example until I'm 1,000% sure there's a legitimate need to expand it.

Reply

[-]

tom_yum@reddit

I run a lot of rhel machines on xfs and never had a problem.

Reply

[-]

NoRecognition84@reddit

I stopped using XFS except in cases where it is the default FS specifically because it doesn't handle shrinking a volume, after discovering this "feature" the hard way once.

Reply

[-]

ipaqmaster@reddit

Yeah it's a nightmare for anything virtualization related. The moment you're in a situation where shrinking needs to be happen it's an entire ordeal to juggle everything into a new partition or temporary location one way or another to juggle it back onto a resizable filesystem instead.

Reply

[-]

draconicpenguin10@reddit

Because I've never seen a compelling reason to choose XFS over EXT4 or BTRFS. My Gentoo systems use BTRFS and I haven't had any major issues.

Reply

[-]

lustriousParsnip639@reddit

Xfs was the default fs in RHEL for a couple of releases

Reply

[-]

Mutant10@reddit

No zstd compression and no checksumming.

Reply

[-]

lightmatter501@reddit

Hardware failures is a big one. ZFS will give you warning when a drive is starting to fail. It also never trusts any drive, because the ZFS team found so many drives that lied in their testing. Yes, you lose performance, but making sure the data is safe is the primary duty of a filesystem, everything else comes after that.

Reply

[-]

ECrispy@reddit (OP)

ZFS is an outlier - its not extent based, it doesn't use any of the usual drivers/modules, it does its own thing, and with that come its own set of limitations and high requirements. Frankly its an enterprise class OS that has had way too much popularity and people think they should be running it at home.

Reply

[-]

lightmatter501@reddit

At home I don’t need the raw performance of enterprise and I care very much about my data. Seems like the perfect place for a slower but more careful fs to me. Now, I’m also very familiar with the fs, so administering it isn’t really a hassle to me.

Reply

[-]

ECrispy@reddit (OP)

I dont know if for other filesystems, smartmontools would work as well? I know XFS ignores the disk controller so it probably uses its own algorithms. anyway, its certainly not plug and play and not for normal users.

Reply

[-]

jaskij@reddit

I followed some suggestions somewhere, had xfs. With 64 bit inodes. It broke so many Steam games it wasn't even funny. The game partition is, and will firmly remain, ext4 with it's default 32 bit inodes.

Reply

[-]

Diabotek@reddit

I only use COW because of snapshots. That's the only reason.

Reply

[-]

Academic_Yogurt966@reddit

For me the biggest issue is not being able to shrink the partitions to be honest. I still use it though. I think Gentoo recommended it when I installed so after two crashed and unrecoverable Btrfs systems I decided to not care about shrinking anymore. XFS has been absolutely rock solid for me.

Reply

[-]

whosdr@reddit

> For me the biggest issue is not being able to shrink the partitions to be honest. Yeah this is kind of a big deal to me too, and it seems to have just been shrugged off here. It's probably because I tend to oversize a partition until I know I don't need the extra space, rather than having to do a big shuffle of all my partitions to grow it a little.

Reply

[-]

Academic_Yogurt966@reddit

>> For me the biggest issue is not being able to shrink the partitions to be honest. > >Yeah this is kind of a big deal to me too, and it seems to have just been shrugged off here. It's probably because I tend to oversize a partition until I know I don't need the extra space, rather than having to do a big shuffle of all my partitions to grow it a little. I just use entire disks to be honest, and I have a spare one for distro hopping so it's not an issue anymore. But I can understand if you only have one disk and suddenly realise you want to install another OS bare metal and haven't got somewhere else to put it. I could probably just as well use ext4 or something to be honest, the only reason I went for XFS was a recommendation on the Gentoo wiki.

Reply

[-]

whosdr@reddit

I tend to get a single large drive (Generally an NVMe SSD. Currently 2TB, looking to upgrade to 4), and partition it out for various use-cases. e.g. A 1TiB partition for games, 200GiB for VMs, 200GiB for my home, 100GiB for root, etc. I have a few reasons for that, from using different filesystems for different jobs, for ensuring I can't fill my root filesystem by accident, using rsync for backup to a remote server (with the option to avoid filesystem boundaries), etc. It works well for me, but it does mean I ocassionally grow, shrink and move partitions about a couple times a year. It's 100% a power user thing but it's still enough to put me off a filesystem if I just..can't.

Reply

[-]

Academic_Yogurt966@reddit

Yeah there are valid reasons for sure. My use case is a 1TB drive for Linux and then a separate nvme for Windows (VFIO), a 2TB storage SATA SSD and a 500GB for fun nvme for other OS:es so volumes filling up unexpectedly isn't really a concern. I sit at like 130GB used out of 1TB on my Linux system so I'll have some time to contemplate how to solve my issue before I get close to filling it up. It's not as if I run a server of some sorts and have to deal with the possibility of an application filling up /

Reply

[-]

whosdr@reddit

I don't think filesystem performance in this day and age of ultra-fast SSDs is really a big factor. I use BTRFS myself, part of that is because I already understand how it functions. It's also because, as you mentioned, the tooling is already there from Snapper/Timeshift. I also already know how to write boot config files to support it. I don't think lazy is the right term, but it would take effort to change without seeing any good reason to do so. Do you have an argument for XFS over BTRFS for somebody who already uses BTRFS (with full snapshot usage) on NVMe SSDs? Is there an equivalent to btrfs-send? How do you boot from a snapshot? etc. (Plus distro support is pretty important too for adoption. Install Mint with a btrfs root partition and it sets up subvolumes automatically, configured to Timeshift's preferred layout for creating snapshots.)

Reply

[-]

ECrispy@reddit (OP)

I think you are correct, and no, I don't have good arguments. I will say I have read plenty of posts like 'btrfs causing 500GB writes to ssd daily' as well as posts about corruption. Or people saying how apps open faster using f2fs/xfs on ssd. I don't know enough about btrfs. I tried to use it \~3 years ago with the integrated snapper and snapshots on every single dnf/pacman hook (tried Arch and TW). I remember the partition layout was non standard and I had to do some manual work. No dount this is fixed now. Then I tried to recover the system to an earlier state. And some apps were failing. My backup strategy is simple, just plug in external drive, copy. Version history is much less imp to me, in 15 years of using GoogleDrive/Docs/Dropbox I think I've used previous versions maybe 3-4 times. I also have older hw, e.g. older Thinkpad T430 with a sata 128gb ssd that was refurb to begin with. I don't really want to risk things esp if it buys me nothing. On a technical note, CoW fs will always have a penalty esp as they get close to being full. There's no getting around it. Do I want snapshots every hour and being able to recover any file to an older state etc. I'm not sure. I want a fast simple predictable system.

Reply

[-]

whosdr@reddit

> I will say I have read plenty of posts like 'btrfs causing 500GB writes to ssd daily' as well as posts about corruption. Yeah there were some kernel versions with a metadata bug. It was fairly simple to fix with a single command, and reverting a kernel for a while. Not ideal for sure. > Or people saying how apps open faster using f2fs/xfs on ssd. Maybe, I haven't yet seen any slowdowns I can notice in the past 4 years. But I expect performance is also partially based on CPU and the kind of SSD. SATA SSD on a slower CPU I imagine would be slow. I'm running NVMe on a 7800X3D, which is about as fast as you can get. > I remember the partition layout was non standard and I had to do some manual work. No dount this is fixed now. Ah fair. I've only used it on distros which automatically configure it out-of-the-box (Linux Mint with Timeshift, OpenSUSE Tumbleweed with Snapper). > My backup strategy is simple, just plug in external drive, copy. Version history is much less imp to me, in 15 years of using GoogleDrive/Docs/Dropbox I think I've used previous versions maybe 3-4 times. Admittedly I don't do much in the way of backups for my root. I mostly use rsync to remotely backup my home. But for version history, btrfs timeshifts have saved me maybe a few dozen times over the past four years. I have daily snapshots, snapshots before big distro updates, snapshots when updating MESA/Firmware, or before updating Nvidia drivers before switching to AMD. (On both sides I've had updates that lead to a black screen or even a full system lockup, so booting/reverting a snapshot has saved me hours a time.) > On a technical note, CoW fs will always have a penalty esp as they get close to being full. I oversize the partition. The loss of 100GiB of space is nothing for the convenience it's provided me over the years. (But I use multi-TB SSDs so it's only something like 5%.)

Reply

[-]

prueba_hola@reddit

BTRFS FTW

Reply

[-]

bilbobaggins30@reddit

EXT4 is what 99% of Distros default to. BTRFS is the other one that Fedora & OpenSuse default to. People aren't going to fuss over File Systems when they don't know better. To me: XFS is reliable & performant enough that I use it.

Reply

[-]

elrata_@reddit

Well, there are a lot of things to choose on your desktop and you can't benchmark everything and repeat that every month. So there is a balance, and some things change when they cause you pain. Familiarity is also a big factor, and once you know the tools, how it fails, the tools to recover from failures and all, there is some inertia also there. I think XFS makes sense for several setups on servers (and almost a must for scylladb or things like that). I haven't questioned it for my desktop in a while (and if I'll question then barfs and those should also be nominated), my current FS doesn't cause me any pain and I've used it for more than a decade (2 if you count ext2/3/4) in my desktop. I'm not sure the FS is where my effort to improve something is best spent on. But I'm open to seeing any evidence on that :) If there is any article that shows a difference in real world desktop scenarios, I'd consider it next time I install my laptop. If it can't translate to any advantage on my usage, then I see little incentive to change.

Reply

[-]

lszhu@reddit

I don’t care performance for my workstation, stability is everything, so I only use ext4.

Reply

[-]

whosdr@reddit

I'd say reliability is my use-case for btrfs. Having been saved from hours of wasted time fixing problems or even full reinstalls by booting and reverting a bad update or package installation on my system. But stability, not had a problem with that yet on btrfs after 4 years so far. If it's not in RAID, it just seems to work. (Even through power outages and forced shutdowns, yet to hit any problems.) But this is just one person's experience.

Reply

[-]

sidusnare@reddit

I use XFS for almost everything, and have since Hans Reiser got arrested. It's database like dump and import make shrinking feasible, though multi-step, I think I've done it twice in over a decade of using it. I use raid and other strategies for failure resistance.

Reply

[-]

rustyrazorblade@reddit

I’ve worked in hundreds of environments and they’re almost all XFS.

Reply

[-]

zeldaink@reddit

I use XFS on HDDs and F2FS on SSDs. Every time I mention F2FS, its either disregarded or someone complains about being rarely used or being prone to dataloss (that can be eliminated with fsync\_mode=strict). Nobody is willing to try XFS or F2FS. ext4 is Linux native and btrfs has kool features. Good old reliable or what the kool kids use. That's your 2 main reasons why. Basically people either don't care or will find some obscure flaw and pretend there's no solution. Sometimes, they already found what works best for them, so there's no point in changing what works best. Maybe the reason why it's not widely used is it's from '93 and was made by SGI, so must be old and outdated? Maybe they're associating X in XFS with X11, so they're ignoring it? Or maybe they just don't want to take risks and use unfamiliar filesystem.

Reply

[-]

ECrispy@reddit (OP)

why f2fs over xfs for ssd, I'm curious? I read some comparisons on phoronix and DJWare channel on youtube (one of the few intelligent Linux channels and not a 'content creator') and it seems xfs is just as fast, and f2fs only benefits on devices with no wear leveling? there's also nilfs which is supposedly even better but not as mature?

Reply

[-]

zeldaink@reddit

F2FS considers the fact that NAND flash storage media has FTL, which brings the wear-leveling. It takes advantage of how it works to ease the life of the flash controller and make better use of it, when possible. That's the primary benefit of F2FS. I'm using it primarily for the transparent file compression. It just reduces writes, doesn't free up space. Not very useful, but XFS doesn't have compression. Never used NILFS, don't know how it compares.

Reply

[-]

Kub1o@reddit

It's not only "good old reliable" because XFS is older than Btrfs but design, can be good when using a giant partition with fixed release but when it comes to modify and dealing with different systems in different situations can be a bit picky, Btrfs/Ext4 having a good backward compatibility makes a lot of difference

Reply

[-]

HeligKo@reddit

I have run into two issues that had me move away from XFS, even though I had better performance using XFS over ext4. The first was the inability to shrink became a problem. The other is it is hard to repair after certain events. I have lost two filesystems that I could have recovered in similar scenarios using ext filesystems. Time to repair after a repairable event has taken roughly twice as long using XFS. I also had more times where I had to interactively do repairs that didn't require interaction with EXT systems. To get the features I wanted for server storage, I moved to ZFS. It has been flawless. One of my use cases has the server and disks in an RV, so the environment is not ideal, and ZFS has never had a problem compared to XFS and EXT4. All that being said, for desktop use I would just use whatever the distro I chose used as its default. I much more likely to use the distro tools for managing things on my desktop, and sticking to defaults makes those work smoother in most cases.

Reply

[-]

skc5@reddit

XFS is a pretty popular default in the server world. Ext4 works fine for most home users’ workloads though

Reply

[-]

RayneYoruka@reddit

I've been using XFS for easily the past 6 years as my OS drives. It's been fine. Yes I use Rhel as my default server distro.. if it's Debian/Ubuntu I stick to ext4

Reply

[-]

ECrispy@reddit (OP)

are you a sysadmin? why not Rocky/CentOS vs RHEL for your private servers?

Reply

[-]

RayneYoruka@reddit

Shhhhh I'm about to migrate to Rocky. I ran a survey about it with a company a few years ago about the whole mess so I was able to see a lot of data about the server distro market.

Reply

[-]

mthode@reddit

I've had FS lockups when using XFS on extremely busy systems (TB sized bitmap files that flipped individual bits pseudo-randomly). iirc it was a known bug and upstream was not interested in fixing it (fight between two subsystem maintainers).

Reply

[-]

ECrispy@reddit (OP)

Interesting. That sounds like it was on a data center server?

Reply

[-]

u25b@reddit

FWIW, my org uses XFS for all our RHEL VMs. Maybe a couple of thousand.

Reply

[-]

vinciblechunk@reddit

I picked xfs for my NAS back in 2008 because it seemed cool and I was a SGI fanboy. Still using it today with zero issues. I probably could have used ext4 just fine, but I didn't.

Reply

[-]

that_one_wierd_guy@reddit

basically it's a matter of missing the boat due to previous issues. and since your filesystem type isn't really something most folk think about unless they have issues. it's hard to make up ground

Reply