作者lantw44 ([+++++++======>])
看板CSIE_WSLAB
标题Re: [情报] 09/25(六)工作站停机及 tmp2 清理
时间Fri Sep 17 23:48:26 2021
※ 引述《oToToT (屁孩)》之铭言:
1F:→ oToToT: 我自己的意思是开不起来当然就没办法清 09/16 11:26
是,这句没有疑问,开不起来当然就不可能清。
2F:→ oToToT: 开得起来的话那一样可以清,除非有人有因为这两台目前没开 09/16 11:27
3F:→ oToToT: 而记不起来自己是不是需要保留上面的档案 09/16 11:27
但是这句的讲法就很奇怪了。按照以往惯例,清 tmp2 前都会公告并且留时间给使用者
备份。使用者无法存取、无法备份的机器,除非硬碟故障,否则资料不应该消失,不会
有「开得起来一样可以清」的状况。也就是说,发公告当下如果有机器无法连上,那应
该在公告内文中明确将这些机器排除在清理计画之外,否则对於曾经使用过目前故障中
工作站的使用者,无法备份资料大概等同没公告直接砍资料。
当然你可能可以说使用者可以要求保留资料,但据我所知清 tmp2 的目的是要求使用者
每隔一段时间必须检视自己放在工作站的资料,同时也让使用者知道这不是永久存放资
料的空间,藉此达到减量的目的。因此公告内容可以看出,应该是以备份为主,真的有
困难时才填表单。
但现在的状况是有些机器上的资料完全无法备份,照理说不应该清理,如果真的要清理,
不就变成是鼓励大家尽量填表单,无论有无重要资料都来填,理由就说工作站断线不能
备份?如果每个人都这样填,我相信多少是会造成工作站管理人员困扰的,也无法达成
原先每学期或每学年资料减量的目的。
4F:→ oToToT: 所以我的想法上在linux10及linux11是与其他台没有太大的差 09/16 11:29
5F:→ oToToT: 别的 09/16 11:29
6F:→ oToToT: 也就没有特别在信中描述这些细节 09/16 11:29
我的想法是公告当下连不上就不能清,公告信应该样要像去年
#1VCN4Uqr 那样,清楚
说明连不上的机器会如何处理,以免造成使用者各自解读、产生误会。
当然我也知道现实状况是管理者最大,管理者有绝对的权力做任何事,没有义务要把公
告写得非常清楚或是揭露相关资讯。但如果可以减少疑点,尽量让大家充分理解公告内
容,那应该有助於提升管理者和使用者之间的信任关系吧。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 140.112.30.246 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/CSIE_WSLAB/M.1631893708.A.B88.html
7F:→ oToToT: 先说我的这些言论都是我自己的,没有跟其他团队成员讨论过 09/18 01:46
我知道在这里讨论的都只是个人言论。我也只是尝试用去年的做法类推今年可能的做法,
发觉这次的公告信不太寻常、猜不透这次的清理计画长什麽样。
8F:→ oToToT: 我的想法上无法连线上就是一种不可抗力之因素 09/18 01:48
9F:→ oToToT: 所以使用者有想保留东西的话可以直接套第三点申请 09/18 01:48
可是连不上这个不可抗力因素和其他状况有很明显的差别。普通的不可抗力因素通常只
是个人的专案、研究需求,属於少数状况;连不上是系统异常,属於普遍状况。如果要
大家为了管理者已知的系统异常状况填表单,总是有些怪异的。
10F:→ oToToT: 而且我的理解上是几乎所有使用者都不会放重要东西在tmp2上 09/18 01:49
我的理解是,目前的制度既然是清理前通知,提醒使用者要备份档案,动机应该是尊重
使用者在 tmp2 存放资料的权利,不预设资料是否重要。否则如果可以这样以部分代全
体,那就把规定改成 tmp2 可随时无预警清空就好了呀。
11F:→ oToToT: 所以某种层度上我会预期大家就算这样也不会特别想填表单 09/18 01:50
12F:→ oToToT: 也不会造成什麽管理者的负担 09/18 01:50
如果我今天这样填表单呢?
工作站帐号:
b00000000,但 /tmp2 下各资料夹里都可能还有我的档案,请保留所有包含我的档案的
最上层资料夹。例如 /tmp2/b00000023/project/report.txt 的拥有者是 b00000000,
那请保留整个 /tmp2/b00000023,底下的档案无论拥有者是谁都全数保留。
档案位置:
[*] linux10
[*] linux11
档案用途:
上学期期末报告和比赛相关档案尚未备份。
其他备注:
由於这两台工作站我连不上,无法确认要保留的资料夹有哪些,上学期又因为分组报告
和比赛而在 tmp2 下许多非自己学号的资料夹存放档案,已经忘记放了多少地方。因此
必须请管理者在清理之前找出所有我有放档案的地方,只要有出现就整个资料夹不论拥
有者全数保留,以确保上课资料完整。
13F:→ oToToT: 应该说我觉得最重要的点应该是跟现在大部分使用者的习惯有 09/18 01:52
14F:→ oToToT: 关,所以我才会用此角度去处理这件事情 09/18 01:52
15F:→ oToToT: 这样才更能减轻使用者以及管理者的负担 09/18 01:53
我觉得最重要的点是这次的公告没有讲清楚连不上的机器会如何处理,造成看信的人需
要再次询问(且不一定能得到回应)才能得知确切处理方式。如果能像去年一样,直接
在信中说明此次异常状况的将如何处理,我相信能减少使用者可能的疑问。在有去年范
本可抄的状况下,多写一句话应该不至於造成管理负担。
把状况说清楚,总是比只讲大纲,要使用者自行推测细节来得好吧。
还有就是类似连不上事件连续两年都发生,但处理方式却完全不同,信中也没有提醒使
用者今年的计划不同於去年。才隔一年就把做法整个换掉,是否会让人觉得政策不连贯,
每年都在做临时决定呢?这也是我在文章最後说的信任关系。维持一致的做法,使用者
较容易预测,也比较容易让双方能互相理解,保持良好关系。
一直以来我都觉得,系上服务和计中服务最大的不同,在於管理者本身也是服务的主要
使用者,比较能够互相理解、照顾到使用者的需求。双方因此较能能维持良好关系,而
不会只是抱怨服务有问题、不好用。
※ 编辑: lantw44 (140.112.30.246 台湾), 09/18/2021 13:20:36
16F:→ oToToT: 就实际上目前没有这种use case ,所以自然没有这种困扰 09/18 21:21
17F:→ oToToT: 如果有这种use case就会考虑各种状况 09/18 21:21
其实我不知道你这里的 use case 是指什麽,不过应该不重要,我就先忽略了。
18F:→ oToToT: 我承认公告发的不是很详尽,但我不认为有谁有误会 09/18 21:21
19F:→ oToToT: 你要说我写得不够周全我觉得没问题 09/18 21:22
好吧,这样说好了,那个看了公告以後误解内容、或是有错误认知的人就是我。
我的推导过程是这样的:
一、发文当下有几台工作站连不上,而且短时间内不会恢复。
二、使用者连不上工作站就不能备份资料。
三、管理团队不会在确认状况前骗使用者硬碟都坏了。
四、管理团队尊重使用者存放资料的权利,不能备份就不能人为删除资料。
五、公告信没有提及何时要清理目前连不上的工作站。
六、公告信外可能另有隐情,推测可能是以下几种状况:
ㄅ、管理团队忘记有工作站还没上线。
ㄆ、管理团队放弃清理发文当下连不上的工作站。
ㄇ、管理团队会安排第二次清理计画,只清理这次没办法清的那几台。
所以我上一篇文章的推文都是围绕在「何时会清第二次」、「是否有规划清第二次」的
问题上,基本上排除了「连不上的也可以清」的可能性,才会说疑点越来越多。
我不知道实际上有多少人会这样想,也许几千个工作站帐号持有者中就只有我一个人有
这种想法,这里就只是提供我个人的思考方式给大家参考。我讲的话不论是在 PTT、电
子邮件、内部聊天群组,都没有任何约束力,没有人会因为我说了什麽就需要去做什麽。
我无意干涉团队运作,只是偶尔会有些「如果是我会怎麽做」的言论。如果有人愿意看、
愿意回应我写的东西,我就该心存感激了,毕竟在 B03 离开以後群组里的人我几乎都
不认识,忽略陌生人的留言也是人之常情。
20F:→ oToToT: 而且目前tmp2就算无预警非人为被清空本来也是本来就写在 09/18 21:24
21F:→ oToToT: 条款里的 09/18 21:24
对,硬碟自然损坏导致资料遗失,这真的有可能发生,以前也确实发生过。但是相较於
每年或每学期的人工清理,发生频率很低,对同一台机器来说通常几年才会发生一次。
因此我觉得硬碟坏掉和人为删除要分开看,不会因为随时可能坏掉就可以随时删除。
22F:→ oToToT: 当然我们不希望这种情况发生,但本来使用者就应该要定期 09/18 21:25
23F:→ oToToT: 备份档案 09/18 21:25
对,备份重要档案本来就是使用者的责任,这没有疑问。这次公告信矛盾的地方在於,
内文叫使用者尽快备份档案,但连不上的机器根本无法备份。叫使用者做一件不可能的
事,本来就容易造成疑问。
我的意思不是说把「备份」这两个字从信中删除。管理者提醒使用者记得备份档案绝对
是正确的,但这次的公告信我以一个平时和管理者几乎没有联系的使用者的角度来看,
我无法 100% 理解管理者希望我怎麽做。
24F:→ oToToT: 而且按照那种填法,他如果是写重要实验资料难以移动 09/18 21:27
25F:→ oToToT: 跟工作站本身连不连的上对我们造成的负担是一样的 09/18 21:28
26F:→ oToToT: 所以这例子本身麻烦的点跟工作站有没有开也没有太大关系 09/18 21:28
我觉得两者还是有差别的。
一、重要实验资料难以移动,无论工作站是否连得上都会发生。虽然我有点怀疑同一
个人是否会同时间和不同的人参与多个跨学期实验,但我们就相信使用者。
二、我上面的例子,如果工作站连得上很可能就不会发生,因为那些并不是需要跨学
期使用或是难以移动的资料,实际上并没有不可抗力因素导致不能删除。
以一个尊重、理解管理工作,能体会管理团队辛苦的使用者来说:
ㄅ、工作站连得上的情况:
一、状况一需要填表单。
二、状况二不需填表单,使用者会自行备份。
ㄆ、工作站连不上的情况:
一、状况一需要填表单。
二、状况二被迫填表单。
我想差别就在於需要填表单的状况变多了。
同时如果工作站在线上,使用者可以(好心)提供要保留的最上层资料夹名称,甚至管
理者可以合理要求使用者给出最上层资料夹名称,否则不受理。在发这篇文的时候,我
有回去看以前发的公告信,管理团队真的曾经要求使用者必须给出最上层资料夹的名称,
不能给复杂路径,也不能叫管理者用各种搜寻条件自行判断。当工作站不在线上,考量
到使用者无法上线确认资料夹名称,自然无法用这类的规定简化作业流程。
顺便说一下,我提的那个例子并不是完全虚构的,而是我遇过的类似状况。我真的曾经
在同一个学期和不同的人分组合作过,并且都使用工作站作为工作区或是档案交换空间。
当然那时候工作站都连得上,我可以自行备份,也就不曾填过表单。
27F:→ oToToT: 当然我相信你是立意良善希望有详尽的公告内容,但我只是想 09/18 21:32
28F:→ oToToT: 表示我觉得这样的公告本身也没有太大会造成多数使用者困扰 09/18 21:33
29F:→ oToToT: 的部分 09/18 21:33
30F:→ oToToT: 我们未来也的确可以有更好的公告内容 09/18 21:33
我无从得知这样的公告内容是否会造成使用者困扰,我只是以一个工作站使用者,同时
曾经是半个工作站管理者的身份,在这里描述我的想法而已。我会说是半个管理者是因
为我不曾当过工作站组(当年叫客户监控组)的组员,但我当时几乎参与了系统组内所
有组别的事务讨论,各组的事情也多少做过、或被要求做过一些。
我相信、也希望别人相信,我在这里写这些东西是立意良善。如果我完全不在乎工作站,
那我大可不必浪费几个小时的时间在这里写回覆。当然有些事情最初可能还是从私人利
益开始,例如当初会参加这个团体是为了自己的需求想要了解、改善服务、探索系统,
顺便获得一点特权、产生一点开源贡献。但我希望整体来说还是带给大家好处的。
31F:→ oToToT: 突然想到政策转弯的部分,我们有确定的政策就只有写在规范 09/18 21:41
32F:→ oToToT: 里的东西,目前没有类似判例或类似的情况是需要参考的吧 09/18 21:41
33F:→ oToToT: 我自己作为使用者也从来没有预期过各项政策每年会一样 09/18 21:44
34F:→ oToToT: 我在规划自己使用工作站的方式从来都只有按明写出来的规范 09/18 21:45
35F:→ oToToT: 而已 09/18 21:45
你说的应该没错,这种小事应该不会重要到有先例一定要遵循,单纯是因为去年发生过
类似的状况,且去年的处理方式很符合我的思考方式(如上面段落所写),才会联想在
一起,认为今年的处理方式没意外的话应该相同。
没有人要求政策必须连贯,我提出这个并不是说有什麽具有强制力的规范要求政策连贯,
而是纯粹的社会(指系上服务使用者,尤其是在校生)观感问题。毕竟每一次的转弯,
使用者可能都要花费精神去适应。例如这次面对的清理计画,某些人可能运气比较差,
刚好选到了停电後开不起来的工作站。这时候就得花费额外时间提问、填表单,说明自
己在哪些地方放了档案。若以去年拆成两次清理,则使用者可直接按照正常流程处理。
试想如果系统组突然宣布从下周开始,工作站上每个帐号只能有 80 个执行绪。或是寒
暑假期间大学部家目录容量限缩为 1000000 KiB,开学才能恢复 2000000 KiB。又或是
每个人同时间只能使用一台工作站的 tmp2,使用第二台随时可能被砍资料。这类型的
政策转弯,会造成现有使用者多大的影响?这些事情目前不一定有明文规范,即使有,
大多也是规范使用者、不是规范管理者。以使用者的观点来看,反正管理者最大,规定
随时都有可能改,改动小一点比较容易应对。毕竟每个人都有自己的事情要做,无法一
直把精神放在处理这些事情上。
也许我多少受了 FreeBSD 说的 POLA (principle of least astonishment) 影响才会
想这些吧。软体升级的时候,希望手动改动少一点。管理规范「升级」时,也希望受影
响的范围小一点。从 2020 砍助教帐号事件开始,系统服务陆续出现多次重大变更。我
相信大多数的服务变更也不是现任团队愿意的,而是有某些外在压力。只能说希望接下
来这几个月没有服务使用规范大地震吧。这不是请求,只是在许愿。
※ 编辑: lantw44 (140.112.30.246 台湾), 09/20/2021 04:54:35
36F:推 aarzbrv: 工作站上每个帐号只能有 80 个执行绪<-cjlin会哀号吧?XD 09/21 10:27
80 个执行绪在这里只是虚构的状况,以现在的环境来说很难再把限制压得这麽低了。
那段我想说的是,即使使用者把工作站使用规范记得非常清楚,每条规则都能背出来,
还是有可能受到这类不涉及使用规范变更的政策改变影响。因此我认为多数使用者能够
正常使用服务,实际上或多或少都依赖管理团队的政策延续。我的观点是,政策连贯对
使用者来说还蛮重要的,即使只是变更这种连明文规范都没有的「现状」,都有可能对
使用者现行使用工作站的方式造成重大影响。
我的意思不是说不能改规定,而是希望只在真的有需要的时候改,可以的话不要改得太
快,使用者可能会跟不上。当然这次的做法改变不算是重大变更,没有改得太快的问题,
只是我无法理解这次改变的必要性,也感觉不出来改了以後有比较好。再加上公告信没
讲清楚,让我觉得有点意外、受到惊吓,因为这项改变可能造成使用者资料遗失。
话说我大一的时候工作站真的是限制 80 个执行绪,那时候我常常踩到这个限制。後来
我在内部会议提议放宽限制,经由多次讨论、修改後,放宽为 Linux 工作站 512 个执
行绪、FreeBSD 工作站 256 个行程,延续至今。如果现在还规定只能用 80 个执行绪,
可能连个桌面环境或浏览器都开不起来吧。
※ 编辑: lantw44 (140.112.30.246 台湾), 09/21/2021 14:41:00
37F:推 aarzbrv: 看到您谈论未经知情同意的情况,在下发现最近有些工作站 09/22 08:40
38F:→ aarzbrv: 好像会经常让来自洋葱路由器出口节点的网路位址连不上 09/22 08:41
39F:→ aarzbrv: ,在下甚至怀疑母系会不会不喜欢电子前哨基金会呀?:~ 09/22 08:42
现在状况如何我不知道,以我那时候来说的话,这类疑似防火墙主动阻挡的问题几乎都
来自计中,系上不太会去挡这种东西。如果可以确定是计中的问题,那再来就是写信问
计中网管看他们是否知情了,有可能是主动挡的,也有可能是防火墙的 bug,他们无法
判断的话可能会要你带着笔电主动到办公室测试。主动挡的有机会可以沟通,防火墙 bug
如果厂商不修就只能看是否能开例外了。
以前我有听学弟说过校内 Tor 连线会有问题,但我自己没试过也不知道状况,不知道
那时候他有没有向计中确认问题发生原因。不过我那时候有以系上系统管理团队的身份
去向计中申请让工作站不要经过各种已知有 bug 的防火墙,一般来说工作站的问题会
比系上其他设备少一些。
不过在这篇(长)文讨论网路问题其实已经离题了啦。
※ 编辑: lantw44 (140.112.30.246 台湾), 09/22/2021 18:45:57
40F:推 aarzbrv: 没关系,还是谢谢您! 09/23 00:24
41F:推 aarzbrv: (但在下今年透过洋葱路由器连计中webmail从没被挡过) 09/23 00:27