File systems!

[SiliconWizard]

ZFS is good but yes, it's resource-intensive. But the fact it's not officially supported by Linux is a major issue for me. Whether one cares about the licensing or not, it's just NOT supported by the Linux kernel, which means that there is no guarantee of any working state between a given version of (Open)ZFS and the kernel. That's a no-no for me. I want to be able to freely update my kernels, and not have this restriction, and have to use specific kernels just for this.

btrfs looks good on paper, but it's a half-baked implementation this far as I got it.

I'm probably going to test XFS on a partition to see how it goes.

As to ZFS, the plan is rather to use it with FreeBSD for my next NAS. My current one was built years ago and runs a RAID array on CentOS, it does the job just fine, never lost any data.

[John B]

BTRFS is the default filesystem for fedora. There must have been some reason?

[DiTBho]

be able to freely update my kernels

can be compiled as kernel module, META gives you min/max supported kernel versions

Code: [Select]

Meta:          1
Name:          zfs
Branch:        1.0
Version:       2.1.11
Release:      1
Release-Tags:  relext
License:       CDDL
Author:        OpenZFS
Linux-Maximum: 6.2
Linux-Minimum: 3.10
(zfs-2.1.11.tar.gz)

when you update the kernel, you get headers and kernel sources in /usr/src/linux, and can recompile openZFS.

[Nominal Animal]

I do tend to use ext4 as my filesystem, but on non-virtual instances, I use it on top of LVM2 for ease of snapshotting and miscellaneous shenanigans.

Similar to how massively widespread use of JS in web stuff has made JS interpreters extremely efficient, widespread use of ext4 in Linux has made it technologically robust and reliable.  My logic: if ext4 + LVM2 suffices, use it; otherwise look into the alternatives.

[Monkeh]

BTRFS is the default filesystem for fedora. There must have been some reason?

Yes, free testing.

[SiliconWizard]

be able to freely update my kernels

can be compiled as kernel module, META gives you min/max supported kernel versions

Code: [Select]

Meta:          1
Name:          zfs
Branch:        1.0
Version:       2.1.11
Release:      1
Release-Tags:  relext
License:       CDDL
Author:        OpenZFS
Linux-Maximum: 6.2
Linux-Minimum: 3.10
(zfs-2.1.11.tar.gz)

when you update the kernel, you get headers and kernel sources in /usr/src/linux, and can recompile openZFS.

Sure, but I don't really want to go through this hassle in this instance. Unless there was an absolutely gigantic benefit.

As I pointed out, one key issue is that the kernel may break ZFS at any point in time, Linus was clear about it, and that makes sense as they can't embed it anyway, so there's no reason to go extra miles to support it as a module. For my use cases, that's not going to be an option. But certainly in cases where you would settle for, say, a given LTS line of kernel with which OpenZFS is fine and tested, why not.

[ejeffrey]

For a boot drive I don't see enough advantage for anything to overcome the stability, support, and universality of ext4.  It's not the best by a long shot but it is good enough l.

For a multi drive array you definitely can do md+lvm+ext4 but I would seriously consider zfs even if there is a bit more hassle because it's not in the mainline kernel.

I have used xfs in the past, especially in the ext3 days.  it's fine, just not really enough of an advantage over ext4 to be worth it to me. 

[magic]

I'm probably going to test XFS on a partition to see how it goes.

XFS is a solid filesystem that just works. It's widely used on large storage servers because it's said to perform faster than ext4, particularly with multiple concurrent accesses. I personally knew people who ditched ext4 for XFS on their servers a few years ago and never looked back. It allocates inode blocks dynamically as new inodes are created, so no stupid problems here. I don't think it does anything fancy with small files, they just get a 4KB block allocated for data and that's it.

The latest XFS v5 (not readable by some old kernels) supports "reflinks", i.e files sharing their data blocks with "copy on write". There is no support (and AFAIK will never be in v5) for true snapshotting, with preservation of inode numbers and everything.

There is probably not much difference on a desktop system. If you start another thread asking which text editor to use on Linux, I will officially declare you a troll

[Marco]

There is no real need for filesystem snapshotting on Linux, thin provisioned LVM does it ... not as conveniently as ZFS though.

[DiTBho]

I have even designed my own toy filesystem (standalone or on-FUSE), which has zero repairing tools and it's far from being fast when it also needs to be robust and reliable. It just works.

This brings us to the question: with which criteria do you entrust your precious data to such a delicate component?

[magic]

zero repairing tools
it works

Pick one.
It will only work until you hit a filesystem or block layer bug, or hardware data loss.

I seem to recall that btrfs also started out with no fsck or repair tools. That's how I knew to give it a pass for now.

[mapleLC]

I'm using ZFS with Proxmox, it looks very stable. 

I find it hard to use for 2 reasons:

The Linux file system is rather confusing.  Etc, bin, dev, sys, srv - it all makes for a lot of necessary domain knowledge to be effective knowing where file locations are

This is kinda Proxmox specific but ZFS is confusing, shares are confusing, and needing to use FTP regularly is annoying

[Monkeh]

I have never used FTP with Proxmox. Why would you need to?

[lyxmoo]

gridefs in mongodb is fast, especially for huge mount of small files (such as fsize < 10kB)

[SiliconWizard]

GridFS is not really a filesystem per se as far as I understand, but is on top of a conventional filesystem: https://www.mongodb.com/docs/manual/core/gridfs/
Unless I missed something.

[SiliconWizard]

One "downside" to XFS is that, while it has a 'discard' option, it apparently hinders performance quite a bit, so if on a SSD, they recommend disabling this option and issuing fstrim separately.
ext4 handles this much better.

[SiliconWizard]

ext4:
 - I found default fixed inode count to not be enough on small size USB drives for a specific workload (gentoo install?).  Reformat required to change
 - My disk partition table got wiped when upgrading OpenWRT once, but my 2nd partition with ext4 was still there and surprisingly easy (lucky?) to fully recover after I found its start and finish address.

The fixed total number of inodes with ext4 looks problematic, but it really is only in pretty particular situations, like indeed with very small partitions and a large number of small files.
Otherwise, I've never had a problem with that.

(Probably obvious for many but just in case: you can have a quick look at your current inode utilization with 'df -i' )

I have 3 different machines running Linux, one is a headless box (for running Linux tools), one is a NAS and the 3rd is a latptop. All have ext4 partitions only, the NAS with LVM (and its boot partition is ext2 for historical reasons, but that's beyond the point.)

inode utilization on each of them never exceeds 16%, even on the NAS where there's a ton of files, and all have been in use for several years.

The default at creation is 1 inode per 16KB of space.

And yes, ext4 is overall pretty resilient and easy to recover.

[DiTBho]

ext4 is [..] easy to recover.

it depends on what you need to recover from.

[DiTBho]

• recover deleted by accident files, with their original file names
• recover files from a damaged filesystem: how logical damages impact the filesystem, how much it degrades, and to what extent
• recover files from a damaged hard disk: how physical damages impact the filesystem, how much it degrades, and to what extent

[DiTBho]

zero repairing tools
it works

Pick one.
It will only work until you hit a filesystem or block layer bug, or hardware data loss.

I seem to recall that btrfs also started out with no fsck or repair tools. That's how I knew to give it a pass for now.

I meant making a testbench to test how a filesystem reacts.

something like ummm, you continuously write files (e.g. scp from a server) of which you know the hash (md5? sha-something), and randomly power down the SBC, then you check for logical damages, how they propagated, if files can be restored (if they), and compare hashes to be sure the content is exact.

[RoGeorge]

ZFS is good but yes, it's resource-intensive. But the fact it's not officially supported by Linux is a major issue for me. Whether one cares about the licensing or not, it's just NOT supported by the Linux kernel, which means that there is no guarantee of any working state between a given version of (Open)ZFS and the kernel. That's a no-no for me. I want to be able to freely update my kernels, and not have this restriction, and have to use specific kernels just for this.

How do you know it's resource intensive if you didn't use it? 

There is no such things as "supported" by Linux.  "Supported by" is about proprietary and closed source OSs.  The Linux kernel has a set of well defined mechanisms to interface with.  Kernel interfacing mechanisms do not change over night, and do not get deprecated/discontinued without warning the users and devs with many years in advance.

There is nothing else you need to do about ZFS when the kernel updates.  You type once "sudo apt install zfsutils-linux" (or whatever install would be for the Linux flavor you use), and that's it.  After that, you can upgrade the kernel or the rest of the OS any time you want, as if you never installed the OpenZFS.  ZFS doesn't need any special attention at a Linux update.

Not trying to convince you to install ZFS, only pointing to misbeliefs.

Aside from the FS question, it's curious to me how nitpicking arguments returned by a search engine can weight more than first-hand testimonies in this very topic, from people saying they used ZFS for years.

Whatever FS you'll choose, keep backups for important/personal data.  A good FS/OS is not enough when it comes to theft, fire, malware, etc.

Good luck testing FSs, and pick the one(s) you like most! 

[DiTBho]

p.s.
if you go for ext*, this is useful for the first-class of the mentioned test-bench

Code: [Select]

sys-fs/extundelete
      Description:   A utility to undelete files from an ext3 or ext4 partition
      License:       GPL-2


[mapleLC]

What about using Ciph as an alternative?

Edit, typo, Ceph

[DiTBho]

just added it to my local overlay, for xfs try this

Code: [Select]

overlay::sys-fs/xfsundelete
      Description:   A utility to undelete files from an xfs partition
      License:       not yet checked


[DiTBho]

What about using Ciph as an alternative?

what is Ciph? URL? any doc?