Btrfs Restoring Support For Swap Files With Linux 4.21

[aht0]

I have extremely limited experience with old Unix stuff, but I'm pretty sure that its Oracle's Solaris (its kernel) supports swap files on UFS.

OpenSolaris did. Also. technically does FreeBSD (+UFS), for that matter. It's not simply used for whatever reason (tradition?). And I do not recall any other BSD that would use swap file.
Installer would always create separate swap partition.

[Charlie68]

Some clarification: this is what OpenSUSE does if you untick the "keep Home separate" and use a btrfs root on installation.

I've been running like that for 2 years now and it was set up and dealt with by the installer, it's not new stuff, they can change the default pretty easily.

Perfectly agree, I was referring to the default settings, which can be easily changed at will, both for the choice of the file system, and for everything else.

[starshipeleven]

OpenSolaris did. Also. technically does FreeBSD (+UFS), for that matter. It's not simply used for whatever reason (tradition?). And I do not recall any other BSD that would use swap file.
Installer would always create separate swap partition.

I recall that back then the whole "swap partition vs swap file" was still a thing. Theoretically the swap partition is better (and it does not rely on a filesystem feature, so it's more "reliable" I guess), plus there is also the thing that placing it as a partition allows you to choose the "fastest disk area" (rotational devices have better performance when reading data on the outer rim of the platter instead than on the internal rim).

But that's all stuff that is mostly negligible with modern hardware and software (swap file functionality has been stable for decades now).

Some reading from the past: https://www.reddit.com/r/linux/comme...wap_partition/

[tildearrow]

Typo.

OK I didn't consider that a typo. Oh wait, I was sleeping anyway. Michael, when do you even sleep?

[pal666]

9 years and its still not stable and reliable?
I guess I will be using ext4 forever.

moron, you missed phoronix coverage of recent ext4 corruption?

[pal666]

Because it has taken 9 years to support file swap.

it always supported swap. swap partition that is. it didn't support swapfiles, but apperently nobody uses them. and it always supported online resize, so you can easily change size of your swap partition without reboots (try that with ext4)

[pal666]

Is ZFS unstable shit? No it's not.

on linux yes it is

[skeevy420]

on linux yes it is

I've been using ZFS as root and for other misc drives for over 3 years now (Arch & Antergos). Once 0.8.0 gets out of RC status I plan on doing a reinstall so I can have an encrypted+deduped ZFS root setup. I'm moving grub to a ZFS formatted USB stick attached directly to the motherboard near my 2nd processor. With all that I'll be able to setup a script that snapshots root and boot because I plan on switching to Gentoo and I'd like the option to snapshot my entire setup before doing a complete rebuild (grub doesn't support ZFS encryption and some other ZFS features so I have to keep GRUB off of my main root+home drive to make full use of ZFS).

I have 48GB of ram. I have the resources to use dedup.

Personally, with ZFS being as good as it is, I just don't see the point of BTRFS outside of not having to worry about the kernel/module upgrade annoyances ZFS brings...I'd rather deal with those annoyances than a not-as-good file system.

[kenjitamura]

moron, you missed phoronix coverage of recent ext4 corruption?

A more recent article pointed out the corruption was caused by BLK-MQ, outside the ext4 driver, and that the corruption affected other file systems as well. It just happened that with most people using ext4 it had looked like only it was affected.

[jacob]

Personally, with ZFS being as good as it is, I just don't see the point of BTRFS outside of not having to worry about the kernel/module upgrade annoyances ZFS brings...I'd rather deal with those annoyances than a not-as-good file system.

The point is that ZFS is far from being "as good as it is". In fact it sucks big time, and not just on Linux. It's block based - seriously! Say hello to internal fragmentation and big overhead, especially when dealing with huge files (one of the things ZFS is known for). I especially "love" the part where it decides to start collating small blocks into bigger blocks to be able to handle the workload.

It doesn't have proper xattr support, instead it handles "attributes" as separate files in a hidden directory. Which means that each "attribute" access requires a full path resolution, and nothing guarantees that "attribute" modifications will be atomic. Now remember that in Linux, ACLs, SELinux labels and other similar stuff are implemented as xattrs, and think of the implications of them being excessively slow and subject to potential race conditions. You can but bang your head against the wall. Yes, I know about the xattr=sa option. Using that means you switch to an incompatible, Linux-only mode that relies on a horrible kludge. Have a look at the source code!

Then ZFS doesn't let you disable CoW per file, like BTRFS does. Instead it has zvols, which are a poor man's substitute for non-cow files. They do the trick more or less as far as using VMs or building disk images goes, but are a pain in the a$$ - in particular because you can't easily use them as an unprivileged user. And they don't work in all cases, sometimes you really just want a file but use random write access (databases come to mind), where CoW is just bad. With ZFS you can either shrug and accept abysmal performace, or use something like a ZIL Slog device for your app that basically caches your random writes and emulates a non-cow file on top of your cow filesystem. Leaving aside the fact that using a dedicated write cache device is not always possible, or desirable, or cost effective, at that stage you may just format it with another filesystem. Generally CoW is a great and highly desirable feature but there *are* cases where it gets in the way and ZFS has no real answer for those.

Of course on Solaris, ZFS used some Solaris kernel primitives to perform simple atomic operations. In the FreeBSD port, they emulate those using... mutexes. Again, bye bye performance. The Linux version inherited that from FreeBSD, despite that fact that Linux does have atomic primitives too (I don't know about FreeBSD).

Oh and by the way, requiring 32Gb or more just for the filesystem to operate properly is beyond ridiculous.

ZFS in my opinion has exactly one killer feature: subvolume encryption, which BTRFS still doesn't support. But other than that, thanks but no thanks. Linux is probably where ZFS has the most users nowadays, but IMHO it's really not worth the hassle. BTRFS has issues of its own, and bcachefs has yet to prove itself, but in either case they are already much better than ZFS in terms of design and usability.