04:18 | tonytee has joined IRC (tonytee!61799dec@gateway/web/freenode/ip.97.121.157.236) | |
04:20 | tonytee has left IRC (tonytee!61799dec@gateway/web/freenode/ip.97.121.157.236, Client Quit) | |
04:20 | tonytee has joined IRC (tonytee!61799dec@gateway/web/freenode/ip.97.121.157.236) | |
04:21 | tonytee has left IRC (tonytee!61799dec@gateway/web/freenode/ip.97.121.157.236, Client Quit) | |
05:07 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
05:09 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
05:46 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
06:12 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3102:f800:5566:1492:a65d:d7f0) | |
06:32 | Statler|Home has joined IRC (Statler|Home!~Georg@p5B30EDB6.dip0.t-ipconnect.de) | |
06:57 | ricotz has joined IRC (ricotz!~ricotz@p5B2A9605.dip0.t-ipconnect.de) | |
06:57 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
08:05 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
09:05 | Statler|Home has left IRC (Statler|Home!~Georg@p5B30EDB6.dip0.t-ipconnect.de, Remote host closed the connection) | |
09:43 | Statler_Office has joined IRC (Statler_Office!~Georg@gwrz3.lohn24.de) | |
09:47 | TatankaT_ has left IRC (TatankaT_!~tim@193.190.253.114, Ping timeout: 240 seconds) | |
09:48 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
10:29 | GodFather has left IRC (GodFather!~rcc@wsip-24-249-172-218.ph.ph.cox.net, Read error: Connection reset by peer) | |
10:29 | GodFather has joined IRC (GodFather!~rcc@wsip-24-249-172-218.ph.ph.cox.net) | |
12:15 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
13:43 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
14:25 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
14:28 | ottch has joined IRC (ottch!~ottch@c-71-62-20-140.hsd1.va.comcast.net) | |
14:39 | jlnl has joined IRC (jlnl!~anon@132.229.188.253) | |
14:48 | <jlnl> I´m setting up a LTSP server for approx. 30 concurrent clients and I´m wondering what would be a practical ratio for partitioning. Is their any filesystem apart from /home that gets filled quickly as more users login to the terminal server?
| |
14:51 | their -> there
| |
14:53 | <alkisg> Use a single partition, it's fine
| |
14:53 | jlnl_ has joined IRC (jlnl_!~anon@132.229.188.253) | |
14:54 | <alkisg> (04:53:19 μμ) alkisg: Use a single partition, it's fine
| |
14:57 | jlnl has left IRC (jlnl!~anon@132.229.188.253, Ping timeout: 240 seconds) | |
14:59 | <jlnl_> alkisg, I tend to at least separate the /var partition so that file placement by end users cannot fill up space needed for logging.
| |
15:00 | <alkisg> jlnl_: it's up to you; I prefer a single file system for schools, so that I only have one point to check etc
| |
15:03 | <jlnl_> alkisg, fair enough. Our users are used to create and move huge files around which neccessitates a separate /var. But no other special recommendations/ requirements to speak of. That is useful information. thank you :-)
| |
15:03 | <alkisg> jlnl_: why separate var instead of separate /home?
| |
15:03 | With separate /home, users can't affect / nor /var
| |
15:04 | And, when you install new programs, you'll know if you have enough space for /var afterwards...
| |
15:14 | <jlnl_> alkisg, not directly, but they can still fill up /tmp for instance. Granted, that won´t happen often, but some of our users are programmers and they tend to generate massive amounts of test data.
| |
15:14 | For such a purpose a separate server would be in order, but I want to design with a failsafe in mind.
| |
15:18 | <fiesh> we use zfs
| |
15:18 | there, you don't have the problem of having to do partitions before, and also it's a better filesystem in basically every regard
| |
15:19 | if you've ever used zfs, you cannot use last generation things like ext234 any more...
| |
15:20 | (for example, we have a cron job that manages automatic file system snapshots, so you have an "undo" for any changes you commit for the last minutes, hours, days, weeks... everybody has used that at some point here)
| |
15:21 | even though all the work we do is version controlled, there does come a time where you mess something up and you're happy there's a snapshot from an hour ago...
| |
16:20 | <quinox> sounds nice, I haven't tried it yet
| |
16:25 | <||cw> zfs is pretty nice. it has some weaknesses when used with samba, but that's usually easily worked around
| |
16:32 | jlnl_ has left IRC (jlnl_!~anon@132.229.188.253, Read error: Connection reset by peer) | |
16:35 | <fiesh> also, you have raid-z, basically a properly done raid system, very convenient
| |
16:36 | the only thing that sucks is that it's third-party kernel modules under linux (zfsonlinux) -- I look into btrfs, but last time I checked its raid functionality was very experimental and one blog I found lamented woes of data loss...
| |
16:38 | ah the documentation has improved, the status is now clearly visible (and still unstable):
| |
16:38 | https://btrfs.wiki.kernel.org/index.php/Status
| |
16:39 | so maybe it'll be an adequate zfs replacement eventually
| |
16:47 | <||cw> there's a bunch of vague warnings around linux zfs raid-z too, recommending mirrors instead
| |
16:53 | <fiesh> we have been using zfsonlinux with two raid volumes for the last 3 years or so, very stable
| |
16:53 | but maybe milage varies
| |
17:09 | although I'd be surprised if there were serious issues, given that zfs is not unique to linux
| |
17:19 | <||cw> I think it's just crash consistency type things, kind of like the raid5 write-hole but not as bad. a UPS helps mitigate I'm sure.
| |
17:23 | <fiesh> ok, I've never run zfsonlinux without a UPS to be honest
| |
17:34 | <||cw> I try not to run anything without a UPS
| |
17:38 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
17:42 | <fiesh> well I guess clients and monitors and the likes don't make too much sense ;)
| |
17:48 | <||cw> i mean anything with important data
| |
17:48 | which sometimes is clients
| |
18:18 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
19:18 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.154) | |
19:36 | Statler_Office has left IRC (Statler_Office!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
20:17 | Statler|Home has joined IRC (Statler|Home!~Georg@p5B30EDB6.dip0.t-ipconnect.de) | |
20:27 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
20:31 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
20:49 | kjackal has left IRC (kjackal!~quassel@2a02:587:3102:f800:5566:1492:a65d:d7f0, Ping timeout: 256 seconds) | |
20:50 | kjackal has joined IRC (kjackal!~quassel@ppp-94-65-231-251.home.otenet.gr) | |
20:56 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.154, Remote host closed the connection) | |
21:02 | adrianor1 has joined IRC (adrianor1!~adrianorg@187.115.106.126) | |
21:05 | adrianorg has left IRC (adrianorg!~adrianorg@179.177.215.6.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds) | |
21:31 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
21:43 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
22:32 | adrianor1 is now known as adrianorg | |
22:44 | Statler|Home has left IRC (Statler|Home!~Georg@p5B30EDB6.dip0.t-ipconnect.de, Remote host closed the connection) | |