| rrq | $ | 11:38 |
|---|---|---|
| LeePen | rrq: £ | 11:51 |
| rrq | € | 11:53 |
| helios21 | Who knows how much longer… for €. | 11:54 |
| joerg | indeed | 12:26 |
| fsmithred | I guess I mis-read that. I was going to offer rrq one of my unused variables. | 12:42 |
| rrq | as for minutae: I'm have a horizontal split qterminal with irssi above and mutt below, and sometimes I confuse where kb focus is. Though usually I catch it before pushing "enter". but I'd appreciate any odd unused variable anyhow :) | 12:48 |
| fsmithred | ¥¥¥¥¥ <- grab some of these instead. | 12:49 |
| onefang | Can I have the even ones rrq isn't using? | 12:52 |
| rrq | other thing: is zfs-fuse as good choice as zfs-dkms? | 12:53 |
| rrq | (as filesystem within a luks encrypted nbd) | 12:54 |
| rrq | as->for a | 12:55 |
| fsmithred | mason might know | 12:56 |
| CueXXIII | zfs-dkms is zfs upstream, no idea if zfs-fuse is feature complete, too. and it would run in user space and require context switching through the kernel to pass the data to processes using the filesystem | 14:14 |
| rrq | performance would be worse, yes. how much though? I've also "worried about kernel | 14:17 |
| rrq | lockup if the nbd falls out | 14:18 |
| rrq | the dm layer for encryption is already a concern; two kernel modules might hold on to each other and force a reboot.. all that is easier to recover from with userland s/w | 14:21 |
| rrq | I'm also thinking that the slow bit here is the network. | 14:26 |
| CueXXIII | yeah, i have no idea about the actual performance, you could run some benchmarks… | 14:30 |
| rrq | knowing very little about zfs, I'm only using it for compression and deduplication | 14:44 |
| rrq | and probably for snapshots (eventually) | 14:46 |
| siewca | rrq: You can use zfs-dkms as regular solution and zfs-fuse as backup, when after kernel upgrade dkms will fail for any reason. | 15:00 |
| rrq | interoperable.. that's good | 15:02 |
| * mason perks up hours later. Reading. | 20:34 | |
| mason | rrq: zfs-fuse, unless something radical has changed, is very much out of date. zfs-dkms is the safer, more maintained bet. What I do here, though, to avoid the carbon impact of building it on every system, is to just build the binary packages and distribute them via a local repository. | 20:35 |
| mason | I haven't refreshed this for some time now, but a snapshot of my stuff as it existed recent is here: https://github.com/ChibaPet/bliss-zfs | 20:36 |
| mason | recently* | 20:36 |
| mason | I want to make it a bit more automated in several respects, as I build it by hand now. Once I have that done I'll publish a new suite of information and tooling. | 20:37 |
| mason | One such goal is to get it building in Jenkins, kicked off by Gitea Actions. As in, see a new kernel published, use automation to update the overall and per-kernel metapackages, publish that, have Jenkins triggered to build it and populate the local repo. | 20:39 |
| mason | That way you never need fear a broken DKMS build rendering you unbootable. | 20:39 |
| rrq | mason: thanks. vary good. I'll have a peek (though not fan of touching microsoft) | 22:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!