On Fri, Oct 12, 2018 at 11:09 PM ~Stack~ <[log in to unmask]> wrote: > > On 10/12/2018 07:35 PM, Nico Kadel-Garcia wrote: > [snip] > > On SL 7? Why? Is there any reason not to use xfs? I've appreciated the > > ext filesystems, I've known its original author for decades. (He was > > my little brother in my fraternity!) But there's not a compelling > > reason to use it in recent SL releases. > > > Sure there is. Anyone who has to mange fluctuating disks in an LVM knows > precisely why you avoid XFS - Shrink an XFS formated LVM partition. Oh, > wait. You can't. ;-) I gave up, roughly 10 years ago, on LVM and more partitions than I absolutely needed. I cope with it professionally, most recently with some tools to replicate a live OS to a new disk image with complex LVM layouts for the filesystem. LVM.... has usually involved complexity I do not need. In the modern day of virtualization and virtualization disk images, I just use disk images, not LVM, to create new filesystems of tuned sizes. Not so helpful for home desktops, I admit, but quite feasible in a "VirtualBox" or "Xen" or "VMWAre" set of Linux VMs. > My server with EXT4 will be back on line with adjusted filesystem sizes > before the XFS partition has even finished backing up! It is a trivial, > well-documented, and quick process to adjust an ext4 file-system. xfsresize is not working for you? Is that an LVM specific deficit? > Granted, I'm in a world where people can't seem to judge how they are > going to use the space on their server and frequently have to come to me > needing help because they did something silly like allocate 50G to /opt > and 1G to /var. *rolls eyes* (sadly that was a true event.) Adjusting > filesystems for others happens far too frequently for me. At least it is > easy for the EXT4 crowd. That's a fairly compelling reason not to use the finely divided filesystems. The benefits in protecting a system from corrupting data when an application overflows a shared partition and interferes with another critical system has, typically, been overwhelmed by the wailing and gnashing of teeth when *one* partition overflows and screws up simple operations like logging, RPM updates, or SSH for anyone other than root. If it's eating a lot of your time, there's a point where your time spent tuning systems is much more expensive than simply buying more storage and consistently overprovisioning. Not saying you should spend that money, just something I hope you keep in mind. > Also, I can't think of a single compelling reason to use XFS over EXT4. > Supposedly XFS is great for large files of 30+ Gb, but I can promise you > that most of the servers and desktops I support have easily 95% of their > files under 100M (and I would guess ~70% are under 1M). I know this, > because I help the backup team on occasion. I've seen the histograms of > file size distributions. Personally, I found better performance for proxies, which wound up with many, many thousands of files in the same directory because the developers had never really thought about the cost of the kernel "stat" call to get an ordered list of the files in a directory. I.... ran into that one a lot, especially as systems were scaled up, and some people got bit *really hard* when they found g that some things did not scale up linearly.y. Also: if you're running proxies, email archives, or other tools likely to support many small files, ext4 only supports 4 Billion files. ext4 supports 2^64. > For all the arguments of performance, well I wouldn't use either XFS or > EXT4. I use ZFS and Ceph on the systems I want performance out of. I've not personally needed those, but I've not been in the big filesystem world for.... a few years. Are they working well for you? > Lastly, (I know - single data point) I almost never get the "help my > file system is corrupted" from the EXT4 crowd but I've long stopped > counting how many times I've heard XFS eating files. And the few times > it is EXT4 I don't worry because the tools for recovery are long and > well tested. The best that can be said for XFS recovery tools is "Well, > they are better now then they were." Five years ago, I was much more leary of xfs. It's been performing very well for me since SL 7 and the upstream RHEL 7 came out. > To me, it still boggles my mind why it is the default FS in the EL world. I suspect its stability has improved. The "large filesystem" specs are pretty good, and the latency numbers do show some benefits.