IRC Logs for #crux Thursday, 2018-01-18

*** abenz has quit IRC00:12
*** chinarulezzz has quit IRC00:20
*** abenz has joined #crux00:26
*** nogagplz has quit IRC00:53
*** nogagplz has joined #crux00:57
*** emmett1 has joined #crux01:03
*** emmett1 has quit IRC01:41
*** pez has joined #crux01:55
*** teK_ has joined #crux03:30
*** fyre has joined #crux03:30
*** tilman_ has joined #crux03:37
*** _________mavric6 has quit IRC03:40
*** _________mavric6 has joined #crux03:41
*** abenz has quit IRC04:14
j_vhas anyone messed around much with zfs?04:30
*** groovy2shoes has joined #crux05:38
jaegerI've used it for years05:51
*** xcko has quit IRC06:20
*** xcko has joined #crux06:21
j_vjaeger: do you use a port for it?07:11
j_vi've only just started seriously considering using it, so i'm still just getting my feet wet learning about installing it.07:12
j_vseems like i want to set up dmks, but i'll look into it more tomorrow.07:16
frinnstbtrfs <307:39
ryu0j_v: i've used ZFS for years too.07:50
ryu0it has more features than BTRFS and has been around longer.07:51
ryu0i'd consider BTRFS for serious use cases though if it was more mture.07:51
ryu0like, you can choose what checksum ZFS uses for data blocks.07:52
ryu0BTRFS, you're stuck with crc32c if you're using data checksums.07:52
ryu0BTRFS and ZFS has different compression algorithms to choose from.07:54
ryu0nowadays i suspect BTRFS has the edge here now that they have zstd support.07:55
*** timcowchip has joined #crux07:55
ryu0at least if you want a more balanced algorithm.07:55
ryu0lz4 from ZFS cares more about speed.07:55
*** abenz has joined #crux07:56
ryu0i found zstd impressive. it's basically a gzip replacement.07:57
joacimnot sure if i like how zfs mounts stuff on its own08:06
joacimi like btrfs, but zfs seems more mature08:06
*** timcowchip has quit IRC08:22
*** workodera has joined #crux08:23
*** abenz has quit IRC08:45
*** abenz has joined #crux08:58
frinnstbtrfs is the bees knees09:13
joacimon linux, i do prefer to use btrfs09:14
j_vhmmm, btrfs definitely is more accessible, since it's already supported in kernel... perhaps i should give that a try while i work on getting a working build of zfs for my system.09:22
joacimstay away from parity raid in btrfs =)09:23
j_vthanks for the heads up09:23
joacimshould be fine for mirrored and striped setups09:24
j_vok, cool, i will probably be preferring mirrored09:25
j_vthat's what i've always done with my soft raids09:26
j_vthat bit about degraded mount is one i will definitely have to review before doing up a mirrored setup09:40
ryu0j_v: they're also the most fault tolerance version of RAID.09:41
j_vdegraded mount note: applies to raid levels with redundancy: needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present.09:43
j_vlooking at git log for 4.14.14's btrfs tree, looking like that issue being worked on actively (maybe fixed in git commit 21634a1, so not a big detractor09:49
frinnsti've run btrfs since 2011. One dataloss (due to me not reading the docs)09:51
frinnstwe run it in production too. It survived my boss' fuckup a lot better than our ext4 disks09:52
frinnst(he unexported our nas) :-)09:52
j_vnice how well it's done for you. i think i'm convinced that it's worth giving it a try... building the btrfs-progs port now09:53
j_vi think i better take some time reading the docs, and besides i've got to power a couple boxes down to move some disks around before i actually get too in depth anyways09:54
joacimhavent gone into subvolumes yet. something i think i shouldve done from the start09:58
joacimright now i just have it mounted directly to /home09:58
*** john_cephalopoda has joined #crux10:06
j_vluckily, i already have btrfs module built for my kernels and a few spare partitions in this box that i can start with10:07
john_cephalopodaACTION . o O ( wrsfs )10:08
frinnstI recommend not mounting the block device and using that. instead, create a subvol and mount that with -o subvol=<mysubvol>10:20
frinnstfor my / i have a rootfs and boot subvolume10:20
frinnstI should probably add my btrbk port to contrib or something10:21
frinnst(its awesome)10:21
j_vwould definitely be interested. ahh, i see you have it at your ports page. nice10:23
frinnstthey require some compile-time dependencies to build the manpages these days :(10:24
frinnstso i've stripped those10:24
frinnstnot really needed on a day-to-day basis. just running the bin print the usage options10:24
j_vno prob, looks like a really cool tool10:26
j_vhmmm, mpup driver still manages to delete ports when there's a connection failure. at least it doesn't delete the whole meta collection, but still, i need to find a way to keep that from happening10:29
frinnsti'd gladly accept patches10:33
j_vi'll look at it before that day is out, shouldn't be to hard if i don't act too obtuse =)10:35
frinnstI have som glibc fun to look forward too10:40
cruxbot[compat-32.git/3.3]: mesa3d-32: 17.2.8 -> 17.3.210:50
cruxbot[compat-32.git/3.3]: talloc-32: 2.1.10 -> 2.1.1110:50
cruxbot[compat-32.git/3.3]: libgcrypt-32: 1.8.1 -> 1.8.210:50
cruxbot[compat-32.git/3.3]: kmod-32: 24 -> 2510:50
cruxbot[compat-32.git/3.3]: gtk-32: 2.24.31 -> 2.24.3210:50
cruxbot[compat-32.git/3.3]: glib-32: 2.54.2 -> 2.54.310:50
cruxbot[compat-32.git/3.3]: freetype-32: 2.8.1 -> 2.910:50
j_vi've got a simple work around, just a hack by faking the sync file... should probably rewrite the deletion logic to check the etc/mpup.lst instead of checking if the port was sync'd10:50
*** abenz has quit IRC10:55
j_va simple: grep -E '^[^#].*[[:space:]]?$PORT$' $LIST_FILE seems to answer if the port is still active in the mpup.lst file, so i'll try that for a bit to see if it breaks anything10:57
j_vwill probably need double quotes instead of single quotes or the $PORT variable won't expand10:59

Generated by 2.14.0 by Marius Gedminas - find it at!