Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux 5.1 Arrives

zdnet.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Linux 5.1 Arrives

#31

Post by wahern »

ComputerGuru wrote: post #5
burtonator wrote: post #3

Earlier quoted context omitted.

How is ZFS in general vs btrfs? ZFS is basically killed by Oracle right?

btrfs is a dumpster truck on fire and everyone serious about their data has switched to ZoL or is holding out in hopes that bcachefs won't be a similar clusterfsck (which shouldn't be too hard to do).

HAMMER2 is the outside contender. See https://en.wikipedia.org/wiki/HAMMER2 (summary) and http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD... (design document)

It's BSD licensed, among other useful characteristics.

Re: Linux 5.1 Arrives

#32

Post by kjeetgill »

One of the coolest new features was just on HN: Efficient IO with io_uring, the new async I/O interface in Linux 5.1 https://news.ycombinator.com/item?id=19843464

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.

Re: Linux 5.1 Arrives

#33

Post by greggyb »

24gttghh wrote: post #10
greggyb wrote: post #8

Earlier quoted context omitted.

SSD on DIMM.

So, a RAM Drive? https://en.wikipedia.org/wiki/RAM_drive

No. RAM drives use normal, volatile RAM. Power down and it all goes away. SSD is non-volatile. Power down and it stays.

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.

Re: Linux 5.1 Arrives

#34

Post by noselasd »

jolmg wrote: post #23
haberman wrote: post #14

Earlier quoted context omitted.

Swap has to get paged into real RAM when there is a page fault (presumably evicting something else). 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.

That seems like an implementation detail done for the performance of prioritizing the use of the faster device. If you need something that's in storage/swap, chances are you're going to need it repeatedly and so it's a performance boost to "swap" that with whatever is being used least in RAM. From a functional point of view, it's still really just expanding your memory with a persistent storage device. > I'm guessing…

Traditional swap is more complicated than that. The kernel can't map it directly as RAM, it has to be paged to and from the backing store and RAM - doing so is not just an optimization.

Re: Linux 5.1 Arrives

#35

Post by silversconfused »

jolmg wrote: post #27
ComputerGuru wrote: post #5

Earlier quoted context omitted.

btrfs is a dumpster truck on fire and everyone serious about their data has switched to ZoL or is holding out in hopes that bcachefs won't be a similar clusterfsck (which shouldn't be too hard to do).

Btrfs has such a bad rep right now, but because such comments like yours lack any specifics I don't know if I should worry if all my systems with a simple btrfs root partition are going to spontaneously corrupt one day. Can anyone give concrete examples of what's wrong with btrfs?

Lilo doesn't support it. Other than that I have no problem with it. I think it had some problems with being declared "prod ready" by some vendors with some certain kernel version, and then a bunch of redhat users went off and tried it with ancient kernels and lost data.

To me, this is just ext4 all over again. That filesystem was _terrible_ in the early days. Ext4 is pretty ok now, just slow...

Re: Linux 5.1 Arrives

#36

Post by silversconfused »

thaumaturgy wrote: post #13

Oh goodie, I get a new kernel version to compile repeatedly for the next few days. 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.

Posting your current config would allow others to see if their own is relevantly different. Sorry I can't help though, I'll be building this for an arm chromebook, not a pc, so my configs will be nothing helpful.

Re: Linux 5.1 Arrives

#37

Post by analogkid »

RussianCow wrote: post #28
analogkid wrote: post #16

Earlier quoted context omitted.

No, OpenZFS is alive and thriving and we use it in production on many Centos systems. 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.

Could you elaborate a bit on what was awful about it?

Sure. Our small ~500GB volume (on an OpenSuse system) became essentially read-only with ~50GB of free space on it. The error code was no free space. We clearly didn't have the "toolkit" needed to deal with such an issue. The box was a secured system, so we couldn't add an additional device easily (non-keyboard USB devices were disabled in the kernel, for example). Also, the read speed off the volume became terribly slow...it would've taken days to get the data off the device. We tried many commands to try to unbork the volume, with no luck. Even some of the btrfs commands were taking hours to run and became unkillable. We had to reboot the box several times...

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.

Re: Linux 5.1 Arrives

#38

Post by Wowfunhappy »

eclipseo76 wrote: post #21
2Ccltvcm wrote: post #18

Earlier quoted context omitted.

ZFS on Linux is where the majority of ZFS innovation is these days. Btrfs should be permanently deleted except for a sole copy in a museum somewhere as an example of a historical mistake negatively affecting millions of people.

Why is everyone shitting on btrfs in this thread?

Apparently because quite a few people have had bad experiences with it? When filesystems go bad, they really go bad, so it makes sense that these users would feel motivated to share their experiences.

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.

Re: Linux 5.1 Arrives

#39

Post by robbyt »

jolmg wrote: post #29
vbezhenar wrote: post #11

Earlier quoted context omitted.

I think that this article explains it somewhat: https://lwn.net/Articles/777212/ 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.

Isn't swap basically expanded memory while using DRAM as cache? It seems like this could be just a different way of operating that cache. I wonder if this new feature would be used with swapon/swapoff or if it would need a different interface.

Intel have a fork of Redis that uses Optane storage instead of RAM. The end result is a persistent DB that can operate at the speed of Redis.
Post reply on HN