HighWayToHell - 计算机
花园里, 篱笆下
2023-08-13T10:38:15+08:00
Druggo
urn:md5:79dfcacdbfd6434dfc57423d51240051
Dotclear
apisix-dashboard etcd 踩坑记
urn:md5:34a0f3abbb4f937d8eb860dd7f345199
2023-08-13T18:30:00+08:00
2023-08-13T18:38:15+08:00
Druggo
计算机
apisixetcdhelm
<p>想用apisix做网关,先在测试环境开搞。</p>
<p>首先需要一套etcd,为了方便就用helm起了一套,顺便启用了tls,结果helm装apisix时遇到问题,etcd居然连不上,似乎证书认证支持有问题 <a href="https://github.com/apache/apisix/issues/5608#issuecomment-979587311" hreflang="en">ref1</a>, <a href="https://github.com/apache/apisix/pull/5640" hreflang="en">ref2</a>,只好先设置不检查证书(verify: false)。</p>
<p>接下来是apisix-dashboard,也连不上etcd,毕竟helm配置里都没有tls相关设置,但是软件本身是支持的,索性自己增加了tls配置,发现还是连不上,证书校验不过,想着也不检查证书吧,可惜软件还没支持,回头看下helm装的etcd是自动生成的自签证书,CN是固定的,只好用cfssl重新签了一套证书,把svc会用到的域名都写进去了,这下终于好了。</p>
<p>等到要上线的时候,想着就不自建etcd吧,腾讯云有提供etcd服务,直接买了,这下又坑了,默认的证书只有vip在SAN里,apisix还好可以不检查证书,但是dashboard又过不去了,这2个软件连etcd的行为不一样,前者只连vip,后者还会获取etcd节点信息然后全部都要连,只有vip在SAN里,那肯定通不过校验啊。</p>
<p>行吧,退掉重新买,这次记得填上了域名信息,以为用域名来连就万事大吉了。结果仍然是打脸了,vip连接没问题,各个节点连接居然还是一样的报错:</p>
<p><code>{"level":"warn","ts":"2023-07-26T10:55:32.904Z","logger":"etcd-client","caller":"v3@v3.5.5/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc00047ce00/10.0.1.95:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: authentication handshake failed: x509: certificate is valid for 10.0.1.95, not 10.0.1.145""}</code></p>
<p>这啥玩意啊,明明用的域名为啥还要拿IP去验证?看来dashboard连etcd节点并没有用域名啊,手工list member 看下,确实节点广播的都是IP地址。。。可是节点的证书SAN里只有vip和域名,可咋整?</p>
<p>又不想自建etcd,购买的也不支持自定义证书,想来想去,得让dashboard连节点时带上域名信息应该就可以通过证书检查了。</p>
<p>Go语言我不会啊,赶紧咨询ChatGPT,立即就给出了带域名的方法,说干就干,一通魔改,重新编译后替换二进制文件,哈哈,成功了!</p>
<p>顺便想起来到社区搜了一下,也有人遇到这个问题,但是始终没有修复,既然耗费我这么多时间,那就顺手提一个<a href="https://github.com/apache/apisix-dashboard/pull/2850" hreflang="en" title="feat: support sni and skipverify option for etcd tls">PR</a>吧,希望可以帮到有缘人。</p>
http://blog.druggo.org/post/2023/08/13/apisix-dashboard-etcd-%E8%B8%A9%E5%9D%91%E8%AE%B0#comment-form
http://blog.druggo.org/feed/atom/comments/295
maven构建加速
urn:md5:b08a824f6b617986a3acac04e440517b
2023-03-09T23:26:00+08:00
2023-03-09T23:34:58+08:00
Druggo
计算机
mavenmvnd
<p>研发同学希望加速构建过程以便更快的部署测试,并找来了官方软件 <a href="https://github.com/apache/maven-mvnd" title="maven-mvnd">mvnd</a>,直接用mvnd替换mvn命令即可,提速很明显,平均约30%,模块越多,提速越多。</p>
<p>下面是当前用的配置,为了稳定常驻后台,避免jenkins job跑完就退出,宿主机弄了定时任务,并发跑三个构建(空项目,就一个pom,内含sleep插件)就会启动好三个mvnd在后台待命。</p>
<pre>
mvnd.logPurgePeriod = 7d
mvnd.idleTimeout = 6 hours
mvnd.threads = 16
mvnd.minHeapSize = 1G
mvnd.maxHeapSize = 3G
mvnd.expirationCheckDelay = 60 seconds
mvnd.duplicateDaemonGracePeriod = 6 hours
</pre>
http://blog.druggo.org/post/2023/03/09/maven%E6%9E%84%E5%BB%BA%E5%8A%A0%E9%80%9F#comment-form
http://blog.druggo.org/feed/atom/comments/291
K8S的探针和优雅关机问题
urn:md5:ec98d42514c9eca572d0f18b9b9e2299
2023-01-08T22:45:00+08:00
2023-01-08T22:51:11+08:00
Druggo
计算机
graceful shutdownk8sliveness probestartup probe
<p>最近折腾起K8S来,顺便整理下遇到的问题。</p>
<p>首先是探针问题,早期版本只有存活探针(liveness probe)和就绪探针(readiness probe),这两个探针没有依赖关系,是同时开始探测的。我总想不明白,程序存活检测都没通过,为啥要浪费时间做就绪检查?等到新版本支持第三个探针:启动探针(startup probe),总算是没毛病了。
为什么要增加启动探针?我想到业务上有些程序启动确实太慢(比如几分钟),以前需要在存活探针加很长的延迟时间(delay),这个延迟其实不好设置,程序随着迭代可能启动更慢,导致需要在fail次数上容忍更多,fail次数更多导致程序运行时被重启的时间被迫也拉长了,这对服务故障恢复不利;又或者程序启动变快了,却又因为延迟是固定的,滚动更新时又白白浪费时间拖慢发布流程。
现在好了,设置启动探针后,只有等启动探针通过后,存活、就绪探针才会开始干活。这就解决了上面提的两个问题,只要启动成功就可以尽快开始服务,不需要像之前那样必须等一个写死的延迟时间;同时存活探针fail次数也可以设置更合理,以便在程序故障时尽快被重启。</p>
<p>另一个问题就是滚动更新时的优雅关机问题,实际情况就是程序开始关闭了,还有业务流量打到这个容器里,导致异常响应。这也很奇怪,K8S本身是知道关机事件的,应该可以提前切走流量才对。网上找到相关文章学习了下,原来是关闭容器开始,切流量和发送关闭信号给容器是同步进行的,但是发关闭信号非常快,而切流量过程本身链路较长(更新etcd,通知ingress,再变更iptables规则等等)实际是异步执行,这两件事之间有时间差,所以程序关闭了,流量还要延迟一会才会切走,导致用户遇到500。因此优雅关机要稳一点还需要在preStop里sleep一会,比如sleep 5,一般流量就切好了。关闭信号会在preStop执行完后发出。
我仔细看了下应用设置,发现preStop里就写了一句stop应用,难怪优雅不起来,流量还没切掉,就主动stop了,增加sleep后问题解决。</p>
<p>顺便又思考了下,为啥会在preStop里主动stop应用?明明K8S会发送关闭信号的啊,测试了下,发现应用没有关闭过程,只等30s超时后被SIGKILL。看来是关闭信号被忽略导致,这里就涉及到容器的init(1号)进程是否会传递信号了,回看应用设置,启动命令是sh,破案了,它不是一个合格的init进程,怪不得需要在preStop里写一个主动stop呢。如果要少写这个stop,可能需要把init程序换一个合适的轻量级init程序,比如<a href="https://github.com/krallin/tini" hreflang="en" title="tini">tini</a>。</p>
<p>ref:</p>
<p><a href="https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/" hreflang="en">https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/</a></p>
<p><a href="https://medium.com/@meng.yan/what-happens-when-deleting-a-pod-d1219c7e1b53" hreflang="en">https://medium.com/@meng.yan/what-happens-when-deleting-a-pod-d1219c7e1b53</a></p>
http://blog.druggo.org/post/2023/01/08/K8S%E7%9A%84%E6%8E%A2%E9%92%88%E5%92%8C%E4%BC%98%E9%9B%85%E5%85%B3%E6%9C%BA%E9%97%AE%E9%A2%98#comment-form
http://blog.druggo.org/feed/atom/comments/289
KVM云主机高负载之二
urn:md5:06fa5b3e4ada1c63049562c182be9963
2020-03-21T13:31:00+08:00
2020-03-21T13:46:56+08:00
Druggo
计算机
hugepageskvmlinuxperformanceqemutransparent_hugepage
<p>一个上线不久,没什么访问量的网站,突然收到用户反馈说页面经常打不开,或者能打开,但是要等十几秒,卡顿非常严重,几乎无法正常使用了,自己人测试下也是相同的表现,看来问题在服务端,排除了网络影响后,就是后端有什么问题了,奇怪的是,并没有任何指标报警啊,服务器一切正常,研发表示也没有啥特别改动,程序日志也很正常。</p>
<p>因为卡顿情况存在,肯定有一个环节请求响应慢了,跟踪下来发现所有卡顿都是同一台云主机,检查监控指标,并不算高,但是看起来会比其他主机上的应用多吃一些CPU,重启应用无效,等手工迁移应用到其他云主机,卡顿问题立即消失,虽然不愿意承认,但是大家觉得云主机的宿主机是不是有什么问题,请厂商帮忙检查,结果是没有问题,一度陷入僵局。</p>
<p>经过仔细对比监控记录,发现有问题的主机上应用在凌晨闲时CPU占用率突然从2%提高到5%,而其他主机上应用一直是2%,我们把怀疑宿主机的依据给到厂商,虽然厂商觉得他们没问题,但是还是愿意帮忙做一下云主机的热迁移。好在热迁移后,问题立即消失,厂商表示不可思议,要求再迁移回来,问题马上复现,经过多次来回检验,厂商终于给出问题可能的原因:透明大页不足,导致分配到了小页,造成虚拟机性能下降。</p>
<p>透明大页完全依赖操作系统分配,如果内存不够富裕,碎片严重就可能无法分配到透明大页(transparent_hugepage),而被分配小页,造成虚拟机页表地址转换开销加剧,性能自然受影响,但是差到这个程度,也是出乎我的意料。难怪很多软件都要求禁用透明大页,可见确实是潜在的性能杀手。</p>
<p>最后解决方案,就是不要使用透明大页,直接使用大页(hugepages),qemu参数 -mem-path 指定即可。</p>
<p>大页是内核支持的预分配内存,一旦分配就从内存统计里消失,和透明大页是完全不同的,具体可以参考内核文档:</p>
<p><a href="https://www.kernel.org/doc/Documentation/vm/transhuge.txt">https://www.kernel.org/doc/Documentation/vm/transhuge.txt</a></p>
<p><a href="https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt">https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt</a></p>
http://blog.druggo.org/post/2020/03/21/KVM%E4%BA%91%E4%B8%BB%E6%9C%BA%E9%AB%98%E8%B4%9F%E8%BD%BD%E4%B9%8B%E4%BA%8C#comment-form
http://blog.druggo.org/feed/atom/comments/275
捡到一次PHP性能提升的机会
urn:md5:1fc4005f21e17375cc5c9d6f339e6c60
2020-03-15T19:05:00+08:00
2020-03-15T19:16:20+08:00
Druggo
计算机
cve-2006-5178open_basedirperformancephpsymlink
<p>PHP的程序并发稍微高一点就慢的不行,sys 消耗出奇的高,除了太慢被切换,平时 strace 总能发现php进程疯狂的stat文件,之前查的不是性能问题,就没有深究。</p>
<p>如果正在使用 open_basedir ,那么好消息,一次性能提升的机会来了;最近考虑升级到7.4,性能可能会好点,结果在更新配置文件的时候突然发现 open_basedir 有一行提示:Note: disables the realpath cache, 天!难怪stat这么多,搜索一通,找到 <a href="https://bugs.php.net/bug.php?id=52312" hreflang="en" title="PHP safe_mode/open_basedir - lstat performance problem">Bug #52312</a> ,没想到的是,这个禁用从5.2时代就开始了,但是这个禁用的提示到7.2才写出来,坑人! 禁用的原因是安全问题 CVE-2006-5178 ,open_basedir 绕过漏洞。</p>
<p>明白原因后,有两种处理方法:第一种,就是不用 open_basedir 了,虽然官方说这个是解决多租户隔离问题的,实际上在别的场景还是有积极意义的,直接关闭确实不太让人好接受;那么第二种办法的话,就是修改源码,注释掉这段逻辑(<a href="https://github.com/druggo/druggo-overlay/blob/master/patches/dev-lang/php/php-74-realpath-cache-openbasedir.patch" hreflang="en" title="enable realpath cache while open_basedir set">patch</a>),同时<strong>保证禁用危险函数</strong>:</p>
<p><q>disable_functions = symlink,link</q></p>
<p>随便测试了几个页面,差不多能获得 20% - 100% 不等的性能提升,大概和包含的文件数量有关系,同时 sys 几乎降到之前的一半了,可以!</p>
http://blog.druggo.org/post/2020/03/15/%E6%8D%A1%E5%88%B0%E4%B8%80%E6%AC%A1PHP%E6%80%A7%E8%83%BD%E6%8F%90%E5%8D%87%E7%9A%84%E6%9C%BA%E4%BC%9A#comment-form
http://blog.druggo.org/feed/atom/comments/274
KVM云主机高负载之一
urn:md5:44a9d9ce4a4996bb3a5790e84260f561
2020-01-20T01:09:00+08:00
2020-01-21T00:51:48+08:00
Druggo
计算机
high loadkernelkvmlinuxqemuubuntu
<p><a href="https://github.com/torvalds/linux/commit/afa8b475c1aec185a8e106c48b3832e0b88bc2de" hreflang="en" title=" x86/timer: Force PIT initialization when !X86_FEATURE_ARAT "></a></p> <p>最近升级了一些Ubuntu的云主机内核,发现系统负载比未升级前高很多,但是物理机升级到此版本则没有问题。</p>
<p>一台跑了7个java程序的云主机,升级前负载基本在1左右,升级后负载跑到7左右,但是CPU基本是一点也不高,回滚内核版本一切又正常了。</p>
<p>经过多次实验,发现官方几个版本内核确实存在问题:</p>
<pre>
4.15.0-70 GOOD
4.15.0-72 BAD
4.15.0-73 BAD
4.15.0-74 BAD
5.0.0-36 GOOD
5.0.0-37 BAD
</pre>
<p>以上测试用一台新云主机啥也不跑,GOOD内核负载0.00左右,BAD内核负载 0.6左右。</p>
<p>尝试安装主线内核 5.4.6-050406,结果是GOOD,可见问题主线内核已经修复掉了。</p>
<p>再尝试官方的HWE内核 5.3.0-24 结果还是GOOD,解决,基本可以收工了。</p>
<p>实际上最近云主机负载问题还有一起(下回说),厂商正在排查,我想既然找到具体版本,不如查一下是哪个补丁的问题吧。</p>
<p>先多找了两家大厂测试,发现问题可以重现,应该不是个别厂商的虚拟化平台问题,翻了下开始出问题的内核补丁,太多了,这块也不熟悉,
干脆两分法逐一排查,经过几十次的内核编译重启,最终找到引入问题的补丁:
<a href="https://github.com/torvalds/linux/commit/c8c4076723daca08bf35ccd68f22ea1c6219e207" hreflang="en" title=" x86/timer: Skip PIT initialization on modern chipsets ">x86/timer: Skip PIT initialization on modern chipsets</a></p>
<p>然后以此为突破口找到了修复补丁:
<a href="https://github.com/torvalds/linux/commit/afa8b475c1aec185a8e106c48b3832e0b88bc2de" hreflang="en" title="x86/timer: Force PIT initialization when !X86_FEATURE_ARAT">x86/timer: Force PIT initialization when !X86_FEATURE_ARAT</a></p>
<p>真相大白,QEMU/KVM才会中招,一开始我还觉得是厂商热补CPU bug导致的:)</p>
http://blog.druggo.org/post/2020/01/20/KVM%E4%BA%91%E4%B8%BB%E6%9C%BA%E9%AB%98%E8%B4%9F%E8%BD%BD%E4%B9%8B%E4%B8%80#comment-form
http://blog.druggo.org/feed/atom/comments/273
放弃 btrfs zfs
urn:md5:fd2cf48655e3cb405a0e4a97b9db56bf
2019-12-07T20:41:00+08:00
2019-12-07T20:46:54+08:00
Druggo
计算机
btrfslinuxquotaubuntuzfs
<p>先说 zfs,Ubuntu 16.04 (4.4内核)开始集成,几乎每个月都会遇到高IO挂起问题,升级到 18.04 (4.15内核)后解决,但是要命的问题:不支持docker。</p>
<p>再说 btrfs,磁盘限额功能有<a href="https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1765998" hreflang="en" title="FS access deadlock with btrfs quotas enabled">缺陷</a>,必须关闭quota,否则就是定时炸弹一枚,
最最糟糕的是IO性能随时间急剧下降(跑docker,也就几千个subvolume),可能是CoW导致的碎片太严重?滚一滚日志都能让负载上天。
网上查下,说最好定期跑跑balance,但是跑的太慢,对IO影响也很厉害,遂 ctrl+c 中断之,结果文件系统只读了。。</p>
<pre>
[7296807.472310] BTRFS: error (device sda2) in btrfs_drop_snapshot:9489: errno=-4 unknown
[7296807.482555] BTRFS info (device sda2): forced readonly
[7296807.482557] BTRFS: error (device sda2) in merge_reloc_roots:2429: errno=-4 unknown
[7296807.493321] BTRFS info (device sda2): balance: ended with status: -30
</pre>
<p>没法remount,rw ,只能全关了,卸载,再挂载,太可怕了,还是老老实实用 ext4 吧。</p>
<p>不过用作备份存储和NAS,这两应该问题不大,特别是 zfs 那是相当稳定,毕竟快照是真好用!</p>
http://blog.druggo.org/post/2019/12/07/%E6%94%BE%E5%BC%83-BTRFS-ZFS#comment-form
http://blog.druggo.org/feed/atom/comments/270
苹果系统升级后证书不信任问题
urn:md5:0d06134aadcd62b0f7e85c74b49c6287
2019-10-18T20:59:00+08:00
2019-10-18T21:01:20+08:00
Druggo
计算机
10.15httpsmacosssl
<p>同事升级苹果系统到最新的10.15导致内部系统证书提示无效,换火狐浏览器就没问题(还是火狐好!)。</p>
<p>查了半天,发现是苹果新系统对证书有效性校验的更严格了:<a href="https://support.apple.com/zh-cn/HT210176" hreflang="zh" title=" iOS 13 和 macOS 10.15 中的可信证书应满足的要求"> iOS 13 和 macOS 10.15 中的可信证书应满足的要求</a></p>
<p>看到最后,就是新规定要求2019年7月1号以后签发的证书有效期不能超过825天(两年多一点),我们内部证书都好几年的,刚好签发日期在时间点之后,那么干脆重新签发证书,把签发时间提到6月份就好了。</p>
<p>PS, 这是苹果唯一值得称道的点,安全性。</p>
http://blog.druggo.org/post/2019/10/18/%E8%8B%B9%E6%9E%9C%E7%B3%BB%E7%BB%9F%E5%8D%87%E7%BA%A7%E5%90%8E%E8%AF%81%E4%B9%A6%E4%B8%8D%E4%BF%A1%E4%BB%BB%E9%97%AE%E9%A2%98#comment-form
http://blog.druggo.org/feed/atom/comments/269
cacti 64bit counter need snmp v2
urn:md5:baaf7763a62b7269d5c456e15985bbdf
2019-10-02T14:58:00+08:00
2019-10-02T14:58:54+08:00
Druggo
计算机
64bitcactisnmp
<p>cacti里绘图的网卡带宽超过100M后,需要使用64位计数器,否则图都是错误的,
换64位后,snmp版本至少使用v2,否则取不到数据。害我查半天。</p>
http://blog.druggo.org/post/2019/10/02/cacti-64bit-counter-need-snmp-v2#comment-form
http://blog.druggo.org/feed/atom/comments/266
gtk程序终于可以显示jpg了
urn:md5:77d47abcd17bec38527683e38f781e54
2019-09-28T14:23:00+08:00
2019-09-28T14:23:34+08:00
Druggo
计算机
gentoogqviewgtkjpglibrsvg
<p>8月11号不知道删了什么或是更新了什么,似乎是卸载了jasper后发生的,所有gtk程序都识别不了jpg图片了,只有png图片可以正常显示,这下系统多处图案无法显示,连壁纸都没了,最大影响还是看图软件,gqview没法用,只好临时装gwenview来应急,但是看图太卡。</p>
<p>查了很久都没有结果,jpg相关软件重装更新都无效。。</p>
<p>碰巧今天更新adwaita-icon-theme失败,gtk-encode-symbolic-svg执行报错:
Can't load file: 无法识别的图像文件格式</p>
<p>搜索后发现和librsvg有关系,重新emerge后解决,同时可怕的是gtk顺势重获jpg识别能力!真是匪夷所思!</p>
http://blog.druggo.org/post/2019/09/28/gtk%E7%A8%8B%E5%BA%8F%E7%BB%88%E4%BA%8E%E5%8F%AF%E4%BB%A5%E6%98%BE%E7%A4%BAjpg%E4%BA%86#comment-form
http://blog.druggo.org/feed/atom/comments/265
解决 TOSHIBA 移动硬盘 Linux下使用异常
urn:md5:6d6671aec150dd8eeaf46599d8621c4c
2019-06-23T11:58:00+08:00
2019-06-23T12:54:20+08:00
Druggo
计算机
linuxpatchtoshibausb
<p>到手一块 TOSHIBA DTB305 500G 移动硬盘,计划用来备份电脑的数据,先加密</p>
<pre>
cryptsetup -s 512 luksFormat /dev/sdb
</pre>
<p>居然失败,磁盘一直报错:</p>
<pre>
May 23 23:38:20 mom kernel: scsi 6:0:0:0: Direct-Access TOSHIBA External USB 3.0 0114 PQ: 0 ANSI: 6
May 23 23:38:20 mom kernel: sd 6:0:0:0: [sdb] Spinning up disk...
May 23 23:38:21 mom kernel: .ready
May 23 23:38:21 mom kernel: sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
May 23 23:38:21 mom kernel: sd 6:0:0:0: [sdb] Write Protect is off
May 23 23:38:21 mom kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
May 23 23:38:21 mom kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
May 23 23:38:21 mom kernel: sdb: sdb1
May 23 23:38:21 mom kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
May 23 23:38:22 mom kernel: FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
May 23 23:40:22 mom kernel: sdb:
May 23 23:42:35 mom kernel: sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 23 23:42:35 mom kernel: sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
May 23 23:42:35 mom kernel: sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
May 23 23:42:35 mom kernel: sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 00 00 08 00 00 00 08 00
May 23 23:42:35 mom kernel: print_req_error: critical target error, dev sdb, sector 2048
May 23 23:44:57 mom kernel: sdb:
May 23 23:45:26 mom kernel: sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 23 23:45:26 mom kernel: sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
May 23 23:45:26 mom kernel: sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
May 23 23:45:26 mom kernel: sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 00 00 08 00 00 00 08 00
May 23 23:45:26 mom kernel: print_req_error: critical target error, dev sdb, sector 2048
May 23 23:45:58 mom kernel: sdb:
May 23 23:46:05 mom kernel: sdb:
May 23 23:47:55 mom kernel: sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 23 23:47:55 mom kernel: sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
May 23 23:47:55 mom kernel: sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
May 23 23:47:55 mom kernel: sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 00 00 00 00 00 00 08 00
May 23 23:47:55 mom kernel: print_req_error: critical target error, dev sdb, sector 0
May 23 23:59:15 mom kernel: sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 23 23:59:15 mom kernel: sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
May 23 23:59:15 mom kernel: sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
May 23 23:59:15 mom kernel: sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 00 00 00 00 00 00 08 00
May 23 23:59:15 mom kernel: print_req_error: critical target error, dev sdb, sector 0
</pre>
<p>难道硬盘坏了,查了下SMART完全没问题啊,算了,换veracrypt加密,这次可以了,接着创建ext4,挂载正常,
但是,随手看了下日志,也不行:</p>
<pre>
[ 123.936031] usb 1-2.4: new high-speed USB device number 6 using ehci-pci
[ 124.107699] usb 1-2.4: New USB device found, idVendor=0480, idProduct=a001
[ 124.107703] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 124.107705] usb 1-2.4: Product: USB device
[ 124.107707] usb 1-2.4: Manufacturer: USB device
[ 124.107709] usb 1-2.4: SerialNumber: WQ670000000009252
[ 124.108238] usb-storage 1-2.4:1.0: USB Mass Storage device detected
[ 124.114141] scsi host6: usb-storage 1-2.4:1.0
[ 124.176728] usbcore: registered new interface driver uas
[ 125.154152] scsi 6:0:0:0: Direct-Access TOSHIBA External USB 3.0 0114 PQ: 0 ANSI: 6
[ 125.162002] sd 6:0:0:0: [sdb] Spinning up disk...
[ 126.176026] .ready
[ 126.177651] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[ 126.180276] sd 6:0:0:0: [sdb] Write Protect is off
[ 126.180279] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[ 126.182271] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 126.197549] sdb: sdb1 sdb2
[ 126.203273] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 126.818539] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 126.940855] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 140.651217] sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 140.651222] sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
[ 140.651224] sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
[ 140.651227] sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 01 40 18 00 00 00 08 00
[ 140.651229] print_req_error: critical target error, dev sdb, sector 20977664
[ 140.651242] Buffer I/O error on dev dm-1, logical block 0, lost sync page write
[ 140.661143] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[ 146.950106] sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 146.950111] sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
[ 146.950114] sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
[ 146.950117] sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 1d 84 18 18 00 00 08 00
[ 146.950120] print_req_error: critical target error, dev sdb, sector 495196184
[ 146.950142] Aborting journal on device dm-1-8.
[ 146.953093] sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 146.953097] sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
[ 146.953099] sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
[ 146.953103] sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 1d 84 18 00 00 00 08 00
[ 146.953105] print_req_error: critical target error, dev sdb, sector 495196160
[ 146.953111] Buffer I/O error on dev dm-1, logical block 59277312, lost sync page write
[ 146.953124] JBD2: Error -5 detected when updating journal superblock for dm-1-8.
[ 178.941515] EXT4-fs (dm-1): previous I/O error to superblock detected
[ 178.945445] sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 178.945451] sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
[ 178.945453] sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
[ 178.945457] sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 01 40 18 00 00 00 08 00
[ 178.945460] print_req_error: critical target error, dev sdb, sector 20977664
[ 178.945472] Buffer I/O error on dev dm-1, logical block 0, lost sync page write
[ 178.945494] EXT4-fs error (device dm-1): ext4_journal_check_start:61: Detected aborted journal
[ 178.945499] EXT4-fs (dm-1): Remounting filesystem read-only
[ 178.945506] EXT4-fs (dm-1): previous I/O error to superblock detected
[ 178.949462] sd 6:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 178.949466] sd 6:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current]
[ 178.949468] sd 6:0:0:0: [sdb] tag#0 ASC=0x24 ASCQ=0x0
[ 178.949472] sd 6:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 08 01 40 18 00 00 00 08 00
[ 178.949475] print_req_error: critical target error, dev sdb, sector 20977664
[ 178.949485] Buffer I/O error on dev dm-1, logical block 0, lost sync page write
</pre>
<p>莫非这硬盘对Linux有什么限制?日志文件系统不行,那换成FAT试试,居然好了!这不科学,搜索一通发现可能是硬盘cache的问题:
<a href="https://patchwork.kernel.org/patch/9237359/" hreflang="en">scsi: introduce a quirk for false cache reporting</a></p>
<p>补丁里没有我这块盘的型号,依葫芦画瓢写一个补丁 <a href="https://github.com/druggo/druggo-overlay/blob/master/patches/sys-kernel/gentoo-sources/toshiba_dtb305-sync_cache.patch" hreflang="en" title="toshiba_dtb305-sync_cache.patch">toshiba_dtb305-sync_cache.patch</a></p>
<p>重新编译内核,加密,创建文件系统,读写正常,搞定!</p>
<pre>
[179343.585880] usb 1-2.4: New USB device found, idVendor=0480, idProduct=a001
[179343.585884] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[179343.585886] usb 1-2.4: Product: USB device
[179343.585888] usb 1-2.4: Manufacturer: USB device
[179343.585890] usb 1-2.4: SerialNumber: WQ670000000009252
[179343.586680] usb-storage 1-2.4:1.0: USB Mass Storage device detected
[179343.590799] usb-storage 1-2.4:1.0: Quirks match for vid 0480 pid a001: 20000000
[179343.591052] scsi host6: usb-storage 1-2.4:1.0
[179344.610048] scsi 6:0:0:0: Direct-Access TOSHIBA External USB 3.0 0114 PQ: 0 ANSI: 6
[179344.617874] sd 6:0:0:0: [sdb] Spinning up disk...
[179345.632026] .ready
[179345.633253] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[179345.633258] sd 6:0:0:0: [sdb] Assuming Write Enabled
[179345.633260] sd 6:0:0:0: [sdb] Assuming drive cache: write back
[179345.639144] sdb: sdb1 sdb2
[179345.640371] sd 6:0:0:0: [sdb] Attached SCSI disk
[179346.383257] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[179346.404356] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[179349.378210] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
</pre>
<p>找到一篇写的更详细的:
<a href="https://zohead.com/archives/linux-usbhdd-err/" hreflang="zh" title="Linux下USB 3.0移动硬盘读写错误问题分析">Linux下USB 3.0移动硬盘读写错误问题分析</a></p>
http://blog.druggo.org/post/2019/06/23/%E8%A7%A3%E5%86%B3-TOSHIBA-%E7%A7%BB%E5%8A%A8%E7%A1%AC%E7%9B%98-Linux%E4%B8%8B%E4%BD%BF%E7%94%A8%E5%BC%82%E5%B8%B8#comment-form
http://blog.druggo.org/feed/atom/comments/264
入手最佳便携电脑 Chromebook
urn:md5:4bc3d88785de0d58030240cca7c4b047
2019-06-16T18:57:00+08:00
2019-06-16T19:09:24+08:00
Druggo
计算机
armchromebooklinuxlxd
<p>因为使用频率其实不高,直接某宝买二手,三星 Chromebook Plus (ARM版)1650块。</p>
<p>作为一个外出需要携带电脑的人来说,谷歌本的优势实在太大了:</p>
<ul>
<li>轻便,仅1kg,而且充电口是Type-C,可以和手机共用充电器</li>
<li>便宜,出门在外随便用,丢了也不心疼</li>
<li>支持安卓应用,几乎任意VPN都可以用了</li>
<li>续航长,目测5小时没问题</li>
<li>支持LXD,可以跑原生Linux程序</li>
<li>从引导到磁盘全都有校验和加密,丢失设备不心慌</li>
</ul>
<p>嗯,性能不是我考虑的,出门在外能看网页,能SSH,还可以看电影,足矣。</p>
<p>但,还是有一个缺点,毕竟是谷歌本啊,需要谷歌帐号登录才好用,否则不能科学上网的话,只能匿名登录,啥都保存不了,好在不是每次登录都需要联网,可以接受。</p>
<p>PS,其实一公斤还是重啊,咋就不能造的更轻一点,上次在岛国上手NEC笔记本,轻多了,700多克,开心的想买,一看价格上万笑容都要凝固,本想咬牙,仔细看键盘居然是是大回车,惹不起。。</p>
http://blog.druggo.org/post/2019/06/16/%E5%85%A5%E6%89%8B%E6%9C%80%E4%BD%B3%E4%BE%BF%E6%90%BA%E7%94%B5%E8%84%91-Chromebook#comment-form
http://blog.druggo.org/feed/atom/comments/263
再一个十年,为旧电脑续命
urn:md5:4f1629612ca1274f84b1fb4680301c99
2019-03-03T20:59:00+08:00
2019-03-03T21:32:37+08:00
Druggo
计算机
CPUDDR2GTXPhenom升级
<p>爱机在<a href="https://blog.druggo.org/post/newpchw" hreflang="zh">十年前升级</a>后一直坚挺,但是编译时的高温还是经常自动关机,换了CPU风扇也不见效,怀疑是电源老化,16年买了个全汉400W,似乎不太容易自动关机了。</p>
<p>但岁月不饶<del>人</del>机,年前竟然经常性休眠后唤不醒,插拔大法换电池依然无果,表现就是开机后各风扇一阵响,然后断电,排除法确定是主板归西了,也是挺不容易的,十年来基本上是不掉电状态,不用的时候S3休眠,突然想起有一次启动BIOS还报过一次checksum error,偶发一次没有在意……</p>
<p>心想这电脑最老的部件都有十四年了,不如换台新的好,之前每次电脑故障,我都要动一次换新的念头,最近一次老莫名死机,感觉是主板灰太多,想想换新的支出,不如买个小型吸尘器来医一下,才一百块钱,万一好了就又可以服役了,即使无效,吸尘器对于打扫也是有用处的,最后证明我是英明的,不仅电脑好了,才发现吸尘器真是个好东西!</p>
<p>回到升级的话题,可能是对旧电脑有感情,也可能是翻了下新的硬件还好几千块,默默打开某宝寻找二手,最低代价,换主板吧,支持DDR2的也不用买新内存,CPU原先是两核挺吃力的了,某宝看下AM2主板支持最高的就是翼龙四核 Phenom 9550,顺便同店买适配的主板一共才二百块不到,值了!</p>
<p>再花20块买蓝牙适配器,60块的USB3.0卡,基本上齐活,噢,忘了去年因为老显卡硬解总是报错,当时花298块买了 GTX 750 Ti 以及换了25寸的2k显示器,可以再战十年,哈哈。</p>
http://blog.druggo.org/post/2019/03/03/%E5%86%8D%E4%B8%80%E4%B8%AA%E5%8D%81%E5%B9%B4%EF%BC%8C%E4%B8%BA%E6%97%A7%E7%94%B5%E8%84%91%E7%BB%AD%E5%91%BD#comment-form
http://blog.druggo.org/feed/atom/comments/261
为MySQL管理员准备的PostgreSQL简易指南
urn:md5:87aa7c3927c29da08a2b16e44e2e56c2
2015-10-04T22:49:00+08:00
2015-10-04T22:49:57+08:00
Druggo
计算机
mysqlpostgresql
<p>原文在此: <a href="https://opslife.org/postgresql-for-mysql-administrators/" hreflang="en" title="PostgreSQL for MySQL Administrators">PostgreSQL for MySQL Administrators</a></p>
<p>CDH默认的数据库是postgresql, 一时间还真的弄不明白, 看完以后差不多可以开搞了.</p>
http://blog.druggo.org/post/2015/10/04/%E4%B8%BAMySQL%E7%AE%A1%E7%90%86%E5%91%98%E5%87%86%E5%A4%87%E7%9A%84PostgreSQL%E7%AE%80%E6%98%93%E6%8C%87%E5%8D%97#comment-form
http://blog.druggo.org/feed/atom/comments/260
多网卡多IP策略路由配置
urn:md5:bba651b0685225a615dcc9236b2690b2
2015-10-03T15:35:00+08:00
2015-10-03T16:02:23+08:00
Druggo
计算机
fwmarkiptableslinuxrp_filter
<p>默认外网eth1, 默认路由不用改, 为了正确路由到内网eth0:</p>
<p>新增外网 eth2, NewIP 配置路由:</p>
<pre>
ip route add default via NewGW dev eth2 src NewIP table 200
ip rule add from NewIP table 200
ip rule add fwmark 0x200 table 200
</pre>
<p>配置iptables mangle 表: ( eth0 : LAN )</p>
<pre>
-A PREROUTING -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark
-A PREROUTING -i eth2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x200
</pre>
<p>配置rp_filter:</p>
<pre>
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
</pre>
http://blog.druggo.org/post/2015/10/03/%E5%A4%9A%E7%BD%91%E5%8D%A1%E5%A4%9AIP%E7%AD%96%E7%95%A5%E8%B7%AF%E7%94%B1%E9%85%8D%E7%BD%AE#comment-form
http://blog.druggo.org/feed/atom/comments/259