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
*** g0relike-2 has joined #crux11:25
*** g0relike has quit IRC11:28
j_vfrinnst: you want me to email that patch for mpup? or just paste it?11:28
frinnstemail plz11:28
frinnstwe have a repo for mpup that you can git format-patch from if you'd like11:28
j_vyep, cloned, patched, and committed locally11:29
j_vsend to you or a ml11:29
frinnstif you're subscribed the crux-devel list, but either is fine11:30
j_vlet me check, not sure if i'm on that one.11:30
frinnstcheers. I'll give it a spin11:51
j_vi've been meaning to get to that, anyways. though, perhaps i should have added a [[:space:]]* before the [^#]... does a comment require that the '#' is first character in the line?11:58
j_vi can send a v2 of the patch if need be12:00
*** workodera has quit IRC12:06
*** workodera has joined #crux12:10
*** john_cephalopoda has quit IRC12:20
*** john_cephalopoda has joined #crux12:32
john_cephalopodaHow can I get my packages into contrib?13:47
j_vfrinnst: i'm not so sure that RE in the grep works as i expected it in all cases, i think it could be a bug in either grep or glibc regexp lib, but i'm working on ironning it out13:55
*** [EaX] has quit IRC14:05
*** xor29ah has joined #crux14:09
j_vi think that i will send a v2 with something like this RE: "^[[:space:]]*(httpup|rsync).*[[:space:]]+$PORT[[:space:]]*$"14:29
jaegerj_v: yeah, I've got a simple port for spl znd zfs if you want it... dkms might be handy for them but I've not tried it, I just recompile them when I update the kernel14:47
j_vjaeger: that would be cool. would definitely help to have a start. i'm in no hurry, so when ever you get time is cool...14:53
j_vi'm trying to get back to working on the crux-arm stuff i had going last winter. of course, every time i think i might have time for side projects, something comes up once i get rolling14:56
j_vbut getting zfs/btrfs working seems like would be a good thing for making my boxen more robust14:58
*** chinarulezzz has joined #crux15:04
pedjaFreeBSD has a WIP patch for zstd in zfs, so btrfs should enjoy its 'edge' while it lasts :)15:27
pedjait is interesting that a lot of people seem to prefer jumping thru hoops of getting zfs on Linux to using in-tree btrfs15:33
*** Kruppt has joined #crux15:34
jaegerI only prefer zfs because I've used it for a long time, even outside of linux... I haven't used btrfs much, though15:39
frinnstbtrfs has a reputation for being unstable15:41
frinnstthat was true ~8 years ago, sure15:41
frinnstbut I guess many jumped on the bandwagon and got burnt15:41
joacimi think the only real problem with using btrfs is the zfs zealots that refuse to shut up15:42
frinnstbtrfs development has been pretty slow to be honest15:42
frinnsthell raid5/6 is still unstable15:43
AnselmoIve heard of some people getting problems on raid1 on btrfs (recently ish) but it seems to have worked fine for me ..15:47
Anselmothe only major issue I had was after some really screwy mounting where it had insufficient power for the disks,  and ended up screwing up the FS15:48
Anselmobut all the data was recoverable15:48
frinnstlots of btrfs-parts doesnt get that much love. Only the features that facebook uses seems to be interesting to many of the devs. And the features (snapshots, subvols) that suse like15:49
Anselmowell. . . snapshotting has been quite useful for me . .15:50
jaegerzfs has its own quirks or problems but for the most part has been very solid for me15:54
AnselmoI havent much used it except for things under openbsd15:58
Anselmowhich is usually just system partitions and generally not what I use anyway15:59
jaegerI've used it in solaris, opensolaris, openindiana, freebsd, and linux so far15:59
jaegerMy current NAS pool has existed on all of those except for solaris15:59
jaegercurrently a crux system15:59
Anselmodoes btrfs even have a driver for any bsd ?16:02
jaegerno idea there16:02
AnselmoI dont recall seeing any, but I havent looked as carefully as I could have16:04
pedjafrinnst, relatively slow btrfs development is one of the things I don't understand. Linux is multi-billon industry, it's late 21st century, and yet no robust, dependable and modern Linux FS16:14
pedjasomething 'boring' :)16:15
pedja'boring' is good for a file system16:15
*** frinnst has quit IRC16:16
jaegerbtrfs killed frinnst!16:18
pedjain a library, with lead pipe16:19
john_cephalopodabtrfs killed the radio star!16:21
jaegerthat too16:21
pedjareminds me of a line by one of those health freaks: 'white sugar is the ultimate killer'16:23
pedjaI thought the ultimate killer was a mosquito16:24
john_cephalopodapedja: Your region is probably too humid for the white sugar. But here you have to be careful to prevent being bitten.16:27
*** frinnst has joined #crux16:27
*** frinnst has quit IRC16:27
*** frinnst has joined #crux16:27
john_cephalopodaWhite sugar can reach sizes of several centimeters.16:27
pedjaI am not worried, The Ant-Man will kick its ass in one of the sequels16:31
*** workodera has quit IRC16:40
cruxbot[core.git/3.3]: tzdata: update to 2018b18:33
*** Henschi has joined #crux20:07
*** tsaop has joined #crux20:07
*** wh0pie_ has joined #crux20:27
*** tsaop has quit IRC20:39
*** Henschi has left #crux ("Konversation terminated!")21:09
cruxbot[opt.git/3.3]: nss: updated to 3.3521:11
cruxbot[opt.git/3.3]: nspr: updated to 4.1821:11
cruxbot[contrib.git/3.3]: net-snmp: force single thread build21:54
frinnstj_v: pushed your patch21:59
*** Kruppt has quit IRC22:45
*** SovietPony has quit IRC22:53
*** SovietPony has joined #crux22:55
*** SovietPony has quit IRC22:55
*** SovietPony has joined #crux22:56
*** john_cephalopoda has quit IRC23:03
*** abenz has joined #crux23:04
*** abenz has quit IRC23:14

Generated by 2.14.0 by Marius Gedminas - find it at!