旧金山马拉松志愿者

一年一度的旧金山马拉松开幕,今年因为某些不靠谱的志愿者团队,我们 BURN 临危受命,在23 mi 处水战为大家提供服务,回馈社区。

这活还真的不轻松,从早上6点到中午12点,倒水送水外加为选手们加油。我们的水站的位置,决定了大多数跑者到我们的地方一定都不好受,越业余的跑者则越痛苦。从刚开始 elite 的闲庭兴步,到后来的走路过水站的跑者们,还有各种抽筋的,真的是见识了跑者的千奇百态。结论就是,还是跑得快点好啊,早完早超生 😀

组织者其实还蛮人性的,6个小时关门时间之后,他们还把记录时间的条移到了人行道上很长一段时间,这样晚的一些跑者还能有机会跑到终点拿个奖牌啥的。喝了一口那个Noon,不跑步的时候喝真的暴暴暴难喝啊…..

psFo8yCl7vnMMcjUkqa2MTniZuQiJ-zsSVhsuizSTb5z=w2668-h2002-no

JOeIa3acN70LQjjsK-nJrlCSrkX9rTgbF_vBglJKK6OJ=w2668-h2002-no

登顶 Mt. Shasta

两年前因为天气原因铩羽而归,在差 700 ft的地方折返的 Mt. Shasta,今年终于成功登顶。Mt Shasta海拔 14,179 ft (4,322m),地处加州北部,是一座复式火山,常年积雪,非常好看。

Mt. Shasta from South Side

Mt. Shasta from South Side

本来爬完 Rainier 今年的登山目标已经完成,然而云腾兄在跑版上的一句“择日不如撞日”让我无比心动。周三的时候,我们五个“心动”的小伙伴们,聚在山景城的老赵川菜商量行程。除了云腾以外,我们四个 (Michael, Lee, bin总和我) 都曾经和 Shasta 扛上过,都爬过且都没能登顶成功,而云腾则是在一个月前成功登上 Whitney,大家状态都不错。

Avalanche Gulch Route

Avalanche Gulch Route

这次的登山路线是 Shasta 最 popular 的 Avalanche Gulch 路线。现在已经是比较 late season 了,一些商业登山团队上周是最后一周走这条线路,主要问题是 Red Banks 上面的雪已经开始化得差不多了。当时 Max 给我们的计划是:

Leaving Sat morning at 7am, get to Shasta town at noon. After a good lunch, arrive at trail head at 1:30. Start back back hiking at 2pm, arrive at High Camp Lake Helen at 5~6pm. Camp at high camp, get up at 3am next day, leave camping gear at camp, start summit route at 3:30, reach peak at 7am, turn around at 7:30, back to camp at 10am, back to trail head by 1pm. Take linch in town and get home by 8pm

我们实际情况要慢一些 (max 太猛!):

6点15分出发 (到我家是6点半),11点到 Shasta town,吃饭,1点到 trail head,6点到 Helen Lake。第二天2点起床,3点出发,休整,3点25再出发,9点10分登顶。9点45分下撤,12点45到 Helen Lake,2点离开营地,5点回到 Trail head,吃大餐,回到家11点。

(more…)

吐个hdfs的槽

其实每个 open source 的玩意儿都会有这个那个的 bug 的,但是这次白白花了一天半的时间,正经活没干,实在是很想吐一个槽。

我们有一个hadoop的机群,最开始是一堆配置低的 pizzabox,每台box有俩 disk,后来加了一些高配置的 beefbox,自从那个之后我们的 cluster 就没有平衡过,亏得于  HDFS-6621 所赐,Balancer 就是一龟速。这也就算了,反正我们也不着急,让他慢慢平衡呗~

然后周四早上,有些 pizzabox 的 disk 就满了,但 cluster 的 utilization 只有不到 50%。我们就怀疑各种 config 问题,比如是不是 dfs.datanode.fsdataset.volume.choosing.policy 设成 Round Robin 啦(之前被咬过),dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction 是不是没设对,或者 dfs.datanode.du.reserved 是不是设太小了。总之排查了一番没有找出什么问题,就先看看 hdfs 能不能自己把几个 volume 之间 balance 一下,就翻到了这个 HDFS-1312 已经开了5年的 task 到现在还是悬而未决。

好吧,那我们就手动搞一下,参照 Hadoop 的 FAQ,貌似也不复杂,只要把 datanode 关掉,挪一下 subdir 到另一个磁盘同样的文件目录下就好了。我们也就这么做了,datanode 上线之后倒是 ok 了,磁盘多了点空余空间,我们很高兴,于是把其他的有问题的 box 都这么搞了。结果过了不久,我们就注意到磁盘又开始满了,我们心中就一股 WTF…

75e60383c11e59fc55673d7c9d75364ba3ed694277f2c45b3c63948a3a8f853a

然后我们又开始一顿排查,又是看源码又是 debug 的,觉得 datanode 没有问题,新 block 也是写到另一个磁盘的。折腾了很久,然后我去比对了一下文件,发现了 dncp_block_verification.log.curr 居然有 1 TB !

7297011354_476b7056be_o

所以我们是撞到了这个 HDFS-6114,我们挪了多少 block,丫又会写一堆 scan log 让我们一阵白挪….. 心里真的是万马奔腾…..

想想 Hadoop 也是有 10 年历史了,怎么还能这么不靠谱……..

登顶 Mt. Rainier

一年一度的登山大戏今年在 Mt. Rainier 展开,并成功登顶。继两年前在 Mt. Shasta 因为天气原因铩羽而归之后,对雪山多了一份敬畏,也更多了一份向往。

Mt. Rainier 全景

Mt. Rainier地处华盛顿州,是喀斯喀特山脉的主峰,顶峰 14,411ft (4,392米),山上被25个冰川覆盖 (原先有26个的,结果一个化着化着就成了snowfield)。这里海拔高,地形多样,成为很多美国本土登山爱好者的训练基地,各路达人也都是从Rainier起步,一些传奇诸如 Whittaker 家族就住在山脚下,Ed Viesturs 也在这里做了20多年的向导。Rainier 的商业登山已经相当成熟,登山成功率也略高 – 平均每年大概有8000-13000人攀登 Mt. Rainier,商业登山团队登顶成功率70%,而独立登山团队成功率只有50%。并且商业登山无比火热,往往要提前大半年预订行程,比如我们在去年 10/5 就订下了今年 7/3 登顶的行程。我们选择了RMI向导,便是 Whittaker 家族经营的,已经有了46年的经验。其他两个著名的向导公司分别是 IMG 和 Alpine Ascents。

Day 1 – Orientation

当天早上抵达西雅图,驱车前往 Rainier 山脚下的小镇 Ashford,也是 RMI 的大本营所在之处。沿途看到几次 Rainier 的全貌,还是很震撼的,想到过两天要爬这个大山,心里一阵激动。我们报的是4 Day Summit Climb,第一天是 Orientation,主要是认识一下向导和其他的组员,讲解一下爬 Rainier 的一些注意事项,以及装备的检查。整个队18人,有一个队员出发前取消了行程,而我们又分成了两个小团,分别有各自的 lead guide,和其他 guide 各2位。登山者和向导比是3:1,意味着之后上山基本是4人一条绳子的节奏。我们的向导还是 RMI 创始人也是著名登山家 Lou Whittaker 的儿子,平时主要帮助哥哥打理酒店,每年带领一两个团上山,真是荣幸。 大本营边上便是 Whittaker 自己的装备租赁处,可以租到需要的装备,倒是很方便 (钱包君恨死我了~)。晚上回去整理了一下所有的装备便拍了一张照片。 YDXJ0317-01 (more…)