|
|
| code logs -> 2023 -> Thu, 14 Dec 2023 | < code.20231213.log - code.20231215.log > |
| --- Log opened Thu Dec 14 00:00:35 2023 |
| 01:10 | | panzerfaus [uid279771@Nightstar-l49s2t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 01:25 | | Vornicus [Vorn@Nightstar-ivektl.res.spectrum.com] has quit [Connection closed] |
| 02:15 | | Kizor [a@Nightstar-nfsqa7.yok.fi] has quit [[NS] Quit: ] |
| 02:28 | | Kizor [a@Nightstar-nfsqa7.yok.fi] has joined #code |
| 03:05 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has quit [Ping timeout: 121 seconds] |
| 03:07 | | Degi_ [Degi@Nightstar-eo4j8k.pool.telefonica.de] has joined #code |
| 03:11 | | Degi [Degi@Nightstar-65kp9t.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 03:11 | | Degi_ is now known as Degi |
| 08:25 | | himi [sjjf@Nightstar-o4k.pal.170.103.IP] has joined #code |
| 08:25 | | mode/#code [+o himi] by ChanServ |
| 14:55 | | Vornicus [Vorn@Nightstar-ivektl.res.spectrum.com] has joined #code |
| 14:55 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 16:23 | | Vornicus [Vorn@Nightstar-ivektl.res.spectrum.com] has quit [Connection closed] |
| 16:37 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has joined #code |
| 17:09 | | panzerfaus [uid279771@Nightstar-l49s2t.irccloud.com] has joined #code |
| 17:50 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [NickServ (RECOVER command used by M-E)] |
| 17:50 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has joined #code |
| 22:20 | <&[R]> | Anyone else interested in decentralized storage? I mentioned that I have a MooseFS pool, but I'm looking at poking at a few other distributed storage systems. Mostly curious if there are any that someone here is interested at looking into that I'm unaware of, I'm going to be looking at: SeaweedFS, Kubo (IPFS), Zookeeper, Bookkeeper, Bob, Tra, Venti, and MinIO. Ceph and GlusterFS do not look all that interesting to me as I'm looking at more JBOD solutions. |
| 22:20 | <&[R]> | Note: I'm specifically interested in network filesystems that can survive at least one server being down. Contrast something like NFS, CIFS/SMB, or diod where if the server you're talking to goes down, you can't access the files until it's back up. |
| 22:21 | <&[R]> | (Might not have mentioned MooseFS here) |
| 22:27 | <&ToxicFrog> | I have in the past poked at IPFS. It's not really a filesystem in the usual sense, though, it's a distributed content-addressed store. You can make it behave like a filesystem, kind of, but it's awkward. |
| 22:28 | <&[R]> | That's fine, venti isn't a FS either :p |
| 22:30 | <&ToxicFrog> | I'm not familiar with any of the others except Ceph and Gluster, neither of which I've actually used. |
| 22:30 | <&[R]> | Fair, I've been kind of hoovering links up to eventually look into |
| 22:31 | <&ToxicFrog> | (all of my previous experimentation with distributed storage has inevitably ended up back at either network drives on a central server using sshfs/nfs/smb, or full replication to all nodes using syncthing) |
| 22:35 | | himi [sjjf@Nightstar-o4k.pal.170.103.IP] has quit [Ping timeout: 121 seconds] |
| 22:38 | <&[R]> | Fair enough |
| 22:38 | <&[R]> | I was doing something like that for a while |
| 22:38 | <&[R]> | But it gets frustrating |
| 22:56 | <&ToxicFrog> | In my experience it works quite well, the biggest issue is that syncthing's multiuser support just doesn't exist |
| 22:56 | <&ToxicFrog> | So if you want to run multiple syncthings for different users on the same node, that's possible, but it's a pain in the ass |
| 22:58 | <&[R]> | Yeah, I was using syncthing for stuff at my last job, worked great, but that was only with one user |
| 22:59 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| 23:00 | <&ToxicFrog> | You end up having to either run a separate daemon for each user listening on a different port, or run syncthing as root and don't let end users configure their shares at all |
| --- Log closed Fri Dec 15 00:00:36 2023 |
|
| code logs -> 2023 -> Thu, 14 Dec 2023 | < code.20231213.log - code.20231215.log > |
|
|