@Oksana XFS for speed AND resilience!

@marcinozga said in Resize Linux VM Ext4 File System Proxmox:

I see few issues above.

LVM is not a filesystem. You don't need to shutdown VM to extend its disk size. You don't need to boot from any installer CD to resize partitions, you can do it from within live system with fdisk, although if you have some unusual partition layout you're probably better off doing it offline. You can also extend filesystem on a live system, no need for shutdown.

correct, didn't think properly when I wrote that. Logical volumes can be put into logical groups that could contain pools of hdd's that can be sees as one, can also move space around easier and have snapshots. I had errors when trying to write the new partition layout hence why I used a live CD. Probably could of looked into it more but didn't want to spend forever on it or mess up any partition data.

@scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?:

@dafyre said in Transparent compression on folders in EXT4/XFS etc?:

@scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?:

@dafyre said in Transparent compression on folders in EXT4/XFS etc?:

@scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?:

@dafyre said in Transparent compression on folders in EXT4/XFS etc?:

Edit: I'm going to put my Zabbix instance on it later and see how it does.

Databases should not be compressed!

Details as to why databases should not be compressed?

Basically because they are always open and written to incrementally. They aren't loaded and rewriteen like most files are. And they tend to be very large, so a very intensive usage pattern.

True. But this compression is being done on the Host OS, not inside the Zabbix VM. I wonder what kind of strangeness this can cause. I don't have a lot of traffic on this particular server.

That doesn't affect anything. Compression is compression.

I'll find out what kind of performance hits I take with it on ZFS. So far, I'm seeing some nice space savings and no problems with anything else.

@ramblingbiped said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@stacksofplates said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@scottalanmiller said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@travisdh1 said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@jaredbusch said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@wirestyle22 said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@jaredbusch said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@travisdh1 said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@scottalanmiller said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@wirestyle22 said in Fedora 26 No Space Left on Device with Plenty of Space Available:

@scottalanmiller I could've sworn there was a post here related to a reboot solving it

Someone mentioned rebooting to try to solve it. But it did not (had already done that.) It was real files causing the issue, nothing orphaned. Literally, we were making 30K files an hour or so.

Tiny files to, right?

That is not relevant except for that fact that large files would have filled drive space and likely been noticed.

How is that not relevant? more files = more inodes being used

Size of the files is not relevant.

It actually makes sense that @scottalanmiller said it was mostly directories. Files of any size will almost always run out of drive space before inodes run out in 99.9999% of situations. This is the first time I've actually heard of this happening, ever.

Only not relevant for those who actually know about inodes already. The only reason I even know about them is they got mentioned in SGI's IRIX Sysadmin courses.

The one major exception is marker files. "touch thishappened" as a file automatically and never clean up and you are using inodes without using any space. That's who you can easily learn about inode depletion. But who does that?

People writing bad scripts that use lock files and forget to remove them.

That wouldn't create enough to do this though.

If you start using configuration management tools to manage infrastructure with code you get the chance to see some of these one-off oddities in the wild a little more frequently than you'd expect. Like having Java developers not use Java's log facilities to manage log rotation, and then having a generic log rotation configuration completely bork things by delete application logs that are still being accessed by the Java application.

I got to see this issue a few dozen times a few months ago before another of our Engineers disassociated the Java applications from our generic log rotation recipe.

Rebooting was the quick fix for us prior to fixing the actual problem.

Oh wow. Everything I have is managed with Ansible ( I can't even log in to servers), however all of the devs use Oracle APEX on separate systems so they don't really touch anything on my stuff. I'm sure I'd have it much worse if I had to manage their stuff.

@momurda said in Testing Filesystem Performance under Linux 4.11 of XFS, BtrFS, F2Fs and EXT4:

ext4 still the defaults on Debian distro as well.

Well Debian, sure. Not surprised there. Fuddy duddy distro 😉

Easy enough to add to XS7 I assume, but sucks that it isn't the default.

So after building a new NFS/SMB vm (and deleting the old one) the new system seems fine.

Something must've got corrupted because of the smartctl errors.

@Dashrender said in Linux: Creating a Filesystem:

I'm assuming LVM will be covered separately - I'm trying to understand what it's purpose is versus just using mkfs.

It will be. And it is unrelated. mkfs and lvm do totally different things. Neither replaces the other in any way.

@Dashrender said:

Right, but when you're working with files that large - why bother storing them in a VM - just st.... OK yeah, that goes against the standard practice now.. so we need a VM, even if the whole host is a VM - welp, I guess your stuck with XFS 🙂

Pretty much. EXT4 is pretty silly for a server of any size, which is why even for desktops RHEL is XFS by default and EXT4 only as an option for advanced users. EXT4's days are pretty much over.