Linux 5.1 Arrives
zdnet.com
zdnet.com
Personally I'm most excited for "Safe signal delivery in presence of PID reuse". I think the kernel/syscall boundary has so many cracks when it comes to race-conditions. It really shows how much has changed with respect to concurrency.
That sounds like swap. What's the difference?
From a functional point of view, it's still really just expanding your memory with a persistent storage device.
> I'm guessing that this is actually mapping the NVM directly into the process, so individual loads and stores write directly to the device instead of actual RAM.
If this were the only difference, then it would be just swap without its main optimization and for no noticeable benefit. I doubt this is all there is to it.
Basically there's Intel Optane DIMM which costs less than DRAM and offers good enough performance, so you can use Optane with DRAM as a cache and those patches provide proper Linux support for that scheme.
I wonder if this new feature would be used with swapon/swapoff or if it would need a different interface.
These chips are extraordinary, when the prices finally go down to a reasonable level it will be another revolution in both persistent (speed) and volatile (size) memory.
DIMM is a form factor and specific bus for getting data from storage on one side of the slot to CPU on the other. This is putting a different type of storage on the other side of that bus.
ZFS is basically killed by Oracle right?
BTRFS works well. I've used it for a NAS since 2012. It started with two mirrored 2 TB WD RED drives. Since then it's gone through an expansion to 6 drives in RAID 10 and two drive failures and replacements. Pretty decent performance and never a serious problem.
I've also used it on two laptops with SSD. It had some weird edge cases there using Docker with a lot of snapshots and running out of space for metadata. Unlike some people, I found it pretty straight-forward to recover by adding more space using either a USB drive or reusing my swap partition.
BTRFS snapshots are easy to do and great for backups and Docker image layers.
I felt the need to write this because your comment got three or four anti-BTRFS responses, and BTRFS has always been good to me.
> ... raid5,6 had serious issues a while back - the write hole problem still exists for btrfs.
it does indeed. BTRFS should not be used on a RAID: https://btrfs.wiki.kernel.org/index.php/RAID56
btrfs is a awful. We used it for a brief time on a production system with vanilla mirrored drives. Absolutely horrible. I will never use btrfs for anything ever again. I've been running unix systems for 30 years; even the darkest days of UFS was not that bad.
We had a 24 hr old copy of the data and we were able to lift the few very important modified files off the device. So we reformatted with XFS and were able to restore the volume to a working state.
Fortunately, the failure happened late on a Friday so we had the weekend to put it all back together again.
I have only hatred for btrfs. Complete crap. Only our business competitors should use it ;-) We only chose to use it on this small system just so that we could get meaningful experience with it. We also had it running on another system where the next weekend we took emergency downtime and removed btrfs from it as well.
I've been using ZFS in production since it was released in Solaris 10 in 2006. It isn't perfect either. We did once hit a performance degradation which was fixed a few days later with a kernel patch. But that was 10 years ago. We never lost any data or sleep over it. We no longer have any Solaris boxes; they were all converted to Centos with ZFS. The main active ZFS pools are all 6TB of mirrored NVMe storage on systems with 2TB of ram and 48 core of INTC Platinum cpu's. Works like a charm.
Uh, no? OpenZFS is being actively developed and maintained, albeit not by Oracle.
- btrfs is fine if you want checksumming for your external HDD with some backup stuff that is mostly sequential i/o.
- For everything else - especially anything that goes beyond a single disk use ZFS. btrfs RAID1 is not really raid1 but rather oddness of pid decides which drive to read from, raid5,6 had serious issues a while back - the write hole problem still exists for btrfs. ZFS stripe, mirror, raidz are well understood and work flawless afaik. btrfs also does strange things when replacing disks, like going read-only when one disk fails - at least it used to be that way.
- performance is a mixed bag but broadly speaking for anything that is not sequential io on an empty disk btrfs is slower than other filesystems[1], for ZFS it depends can be slower or faster than ext4 depending on a lot of settings...
- ZFS tooling is far superior to btrfs - I've used both a lot and you won't go back to btrfs tooling once you've used ZFS.
- btrfs snapshots degrade performance with rising snapshot count. ZFS works fine.
- ZFS has native encryption with zfs send / recv support in the upcoming 0.8.0. So you can do encrypted differential backups this way.
- btrfs quota was for a long time broken and error-prone, not sure what the current status is but it never worked correctly for me.
- ZFS lacks cp --reflink and linux pagecache integration as well as sendfile() on Linux and the ZFS ARC is independed of the pagecache - that has some consequences for e.g. mmap().
- ZVOLs are ZFS only you can create block devices as ZFS datasets i.e. zfs create -V 10G rpool/xfs && mkfs.xfs /dev/zvol/rpool/xfs && mount /mnt /dev/zvol/rpool/xfs can be useful for ceph, running docker on xfs volumes in container
- btrfs works fine inside containers so you can run Docker in LXD/LXC - ZFS is not there yet - overlay2 support is also missing.
- no io-scheduling via cgroups for ZFS afaik because the Linux queue subsystem is not used...
- Last but not least: ZFS has ZIL & L2ARC. ZIL is huge for spinning disks because sync() writes are first written to an ssd storage and later async and sequential to the hdd. TL;DL: apt update and databases are fast even on spinning disks. L2ARC is an SSD-Cache but it's not so effective in my experience (low hitrate for typical hosting stuff)
- Personally I will avoid using btrfs if I can.
1: https://www.phoronix.com/scan.php?page=article&item=freebsd-... it's a little bit apples/oranges because ZFS Freebsd != Linux ZFS but IMHO it shows that the architecture/design is sound.
Might be unfair, but I've learned my lesson there. I decided to follow the spectactle from a large distance.
Perhaps it's a vocal minority, but does it matter? Isn't the error rate what's most important? I've seen ZFS horror stories too, but not nearly as many, and that says something at least.
Disclaimer: I've never used btrfs. I quite like ZFS.
To me, this is just ext4 all over again. That filesystem was _terrible_ in the early days. Ext4 is pretty ok now, just slow...
It's BSD licensed, among other useful characteristics.
That said: ZoL works with Linux 5.0, but AFAIU that’s due to ZoL falling back to less optimal code. I know it works because I run both on my laptop.
If any of you are successfully rocking Linux on an LG Gram (especially the 17Z990), and you have decent ACPI support, I'd loooooooove to see your kernel config file. Please.