Author Topic: File systems!  (Read 10468 times)

0 Members and 1 Guest are viewing this topic.

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14045
  • Country: fr
Re: File systems!
« Reply #25 on: May 21, 2023, 09:21:40 pm »
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.
 

Offline John B

  • Frequent Contributor
  • **
  • Posts: 784
  • Country: au
Re: File systems!
« Reply #26 on: May 21, 2023, 10:31:04 pm »
BTRFS is the default filesystem for fedora. There must have been some reason?
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #27 on: May 21, 2023, 10:41:13 pm »
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.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5966
  • Country: fi
    • My home page and email address
Re: File systems!
« Reply #28 on: May 21, 2023, 10:50:22 pm »
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.
 
The following users thanked this post: SiliconWizard, DiTBho

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7983
  • Country: gb
Re: File systems!
« Reply #29 on: May 21, 2023, 10:58:38 pm »
BTRFS is the default filesystem for fedora. There must have been some reason?

Yes, free testing.
 
The following users thanked this post: magic

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14045
  • Country: fr
Re: File systems!
« Reply #30 on: May 22, 2023, 02:47:40 am »
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.
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3605
  • Country: us
Re: File systems!
« Reply #31 on: May 22, 2023, 04:12:09 am »
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. 
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6715
  • Country: pl
Re: File systems!
« Reply #32 on: May 22, 2023, 05:40:59 am »
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 :D
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6671
  • Country: nl
Re: File systems!
« Reply #33 on: May 22, 2023, 06:02:31 am »
There is no real need for filesystem snapshotting on Linux, thin provisioned LVM does it ... not as conveniently as ZFS though.
« Last Edit: May 22, 2023, 06:05:07 am by Marco »
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #34 on: May 22, 2023, 12:18:54 pm »
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?
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6715
  • Country: pl
Re: File systems!
« Reply #35 on: May 22, 2023, 12:58:02 pm »
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.
 

Offline mapleLC

  • Frequent Contributor
  • **
  • Posts: 326
  • Country: us
Re: File systems!
« Reply #36 on: May 22, 2023, 02:39:37 pm »
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

 

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7983
  • Country: gb
Re: File systems!
« Reply #37 on: May 22, 2023, 02:53:27 pm »
I have never used FTP with Proxmox. Why would you need to?
 

Offline lyxmoo

  • Contributor
  • Posts: 13
  • Country: cn
Re: File systems!
« Reply #38 on: May 22, 2023, 04:29:28 pm »
gridefs in mongodb is fast, especially for huge mount of small files (such as fsize < 10kB)
 
The following users thanked this post: Ed.Kloonk

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14045
  • Country: fr
Re: File systems!
« Reply #39 on: May 22, 2023, 07:56:09 pm »
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.
 

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14045
  • Country: fr
Re: File systems!
« Reply #40 on: May 22, 2023, 08:06:11 pm »
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.
 

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14045
  • Country: fr
Re: File systems!
« Reply #41 on: May 23, 2023, 04:25:50 am »
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.
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #42 on: May 23, 2023, 08:03:05 am »
ext4 is [..] easy to recover.

it depends on what you need to recover from.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #43 on: May 23, 2023, 08:09:30 am »
  • 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
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #44 on: May 23, 2023, 08:20:47 am »
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.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6064
  • Country: ro
Re: File systems!
« Reply #45 on: May 23, 2023, 10:19:29 am »
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!  :-+
« Last Edit: May 23, 2023, 10:21:49 am by RoGeorge »
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #46 on: May 23, 2023, 12:14:39 pm »
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
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline mapleLC

  • Frequent Contributor
  • **
  • Posts: 326
  • Country: us
Re: File systems!
« Reply #47 on: May 23, 2023, 12:32:19 pm »
What about using Ciph as an alternative?

Edit, typo, Ceph
« Last Edit: May 23, 2023, 10:11:06 pm by mapleLC »
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #48 on: May 23, 2023, 01:35:42 pm »
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
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: File systems!
« Reply #49 on: May 23, 2023, 03:53:14 pm »
What about using Ciph as an alternative?

what is Ciph? URL? any doc?
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf