C0reFast记事本

to inspire confidence in somebody.

0%

在Linux系统上支持对用户以及对用户组设置磁盘配额的文件系统很多,常见的Ext4文件系统对配额的支持就很好,但是如果要针对某个目录进行配额限制的话,就比较难办了。
至少在Ext4文件系统上并没有什么好的办法,有些比较hack的办法,比如使用 fuse 挂载一个目录,并在这个文件系统里实现目录级别的配额,虽然可以实现,但是问题就是 fuse 的性能要差很多。
然后调查了一下XFS,XFS文件系统支持 Project Quota 功能,通过该特性,可以支持目录级别的配额限制。

阅读全文 »

服务器的Apache进程突然无法启动了,在错误日志中,有如下信息:

[Mon Feb 13 14:54:10 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.8173) (5)
[Mon Feb 13 14:55:02 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.8823) (5)
[Mon Feb 13 14:56:01 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.9113) (5)
[Mon Feb 13 14:57:01 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.9765) (5)

看了一下磁盘,空间并没有被占满,于是搜索了一下,找到了办法。

阅读全文 »

Monitor部署结束后,需要部署Ceph的OSD,OSD是Ceph实际存储的核心,有了OSD,数据才能正常进行存储,这里还是在一台机器上部署3个OSD,实际生产环境中,会有更多的OSD以及更多的机器。
这里默认机器上已经装好了所有Ceph对应的包。出于简单考虑,所有的OSD只分配一个对应的数据目录。实际生产环境中,一般一个OSD会对应一个设备。

阅读全文 »

Ceph官网上介绍了使用ceph-deploy工具部署Ceph集群的方法,但是手工部署的方法文档中写的不够详细,花了点时间研究了一下,下面是手工部署一个简单的Ceph集群的步骤,先说怎么部署Monitor。

Monitor是Ceph的核心,用于存储所有的元信息,这里部署的是一个3 Monitor的集群,出于简单考虑,这三个Monitor被我放在了同一台机器上,实际部署的话,还是要放在不同的机器上保持高可用。

阅读全文 »

经常会在日志,或者其他地方遇到类似 '\xe4\xb8\xad\xe5\x8d\x8e\xe4\xba\xba\xe6\xb0\x91\xe5\x85\xb1\xe5\x92\x8c\xe5\x9b\xbd' 的字符串,但是不知道实际是代表的什么,因此要做一个解码。

之前一直没有找到比较好的网页的工具,所以就直接尝试用Python进行解码,实际上类似的字符串就是二进制数据,所以作为字符串加上相应的编码decode一下就可以了。

# 前面加上b声明是二进制数据
s = b'\xe4\xb8\xad\xe5\x8d\x8e\xe4\xba\xba\xe6\xb0\x91\xe5\x85\xb1\xe5\x92\x8c\xe5\x9b\xbd'
# 尝试使用UTF-8解码并输出
print(s.decode('utf-8'))
# 如果不行的话,尝试一下GBK
print(s.decode('gbk'))

Python2和Python3通用~

Python 3.6.0 (default, Dec 24 2016, 08:03:08) 
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> s = b'\xe4\xb8\xad\xe5\x8d\x8e\xe4\xba\xba\xe6\xb0\x91\xe5\x85\xb1\xe5\x92\x8c\xe5\x9b\xbd'
>>> print(s.decode('utf-8'))
中华人民共和国

最近需要修改一下Apache的BasicAuth模块,顺便简单分析一下。

首先是 mod_authn_file, 这个模块从文件中读取用户名和密码组合,并逐一check看用户名和密码是否符合。代码在 modules/aaa/mod_authn_file.c

static const authn_provider authn_file_provider =
{
    &check_password,
    &get_realm_hash,
};

//注册一个叫file的AuthProvider,主要是两个函数check_password和get_realm_hash
static void register_hooks(apr_pool_t *p)
{
    ap_register_provider(p, AUTHN_PROVIDER_GROUP, "file", "0",
                         &authn_file_provider);
}
阅读全文 »

前几天拿到了京东云的代金券,87块钱,刚好能用一台1核1G的虚拟机一个月,外加1M的外网带宽。于是就随便试用了一下,感觉还行,说说感受吧。

首先是镜像,目前镜像不是很多,主要集中在CentOS、Ubuntu、Windows。CentOS还是比较全的,从5.8到7.3都有,Ubuntu只用12.04和14.04两个LTS版本,Windows还是有一些的,不过没怎么关注。除了官方的镜像,还有安全镜像,不过我不敢选。不知道里面加了些啥~
我是直接选了一个CentOS 7.3的镜像。

然后是硬盘,87块钱的代金券只能用系统盘了,30G,数据盘不够加了,也没加。

目前网络只有非BGP可选,创建好了之后我是分配了一个电信的IP,地域是华北,不知道会不会有其他运营商可以选择了。带宽也只能选择1M,不然钱不够了~

创建的过程还是挺简单的,我是绑了SSH key,可以直接ssh登录了。

进去了主机看了一下系统信息:

阅读全文 »

某天收到报警,发现某台PHP Web机器的CPU比较高,压力比较大,登录到机器看了一下,发现,user的CPU还行,但是system的CPU比较高,导致了整个机器的负载比较高,于是就怀疑是不是系统某些地方存在性能瓶颈。

于是先用perf+FlameGraph生成了一下火焰图看一下:
火焰图

发现有很多 __lxstat64 调用占用了很多的CPU时间,这个调用是 stat 函数在64位Linux下的实现,正常情况下,PHP不应该会有这么多类似的调用,这是为什么呢?

阅读全文 »

很久之前,对于磁盘的了解,就知道一个很关键的指标MTBF,即相邻两次故障之间的平均工作时间,也称为平均故障间隔,这个值越大越好,越大意味着硬盘更不容易坏。
对于RAID,也是很相信,觉得大多数情况下,使用RAID,就能保证数据的安全性,几乎不会有数据丢失的风险。

突然的,读到一篇对于RAID 6的文章 Why RAID 6 stops working in 2019,这是一篇2010年的文章,很遗憾到目前才读到。
这篇文章里提到了一个指标,叫URE,也就是Unrecoverable Read Error Rate,不可恢复读取错误,一般普通的桌面级别硬盘,这个指标的值为1 × 10^-14,意味着每读取10^14bit的数据,就有可能产生1bit的错误。

问题在于,这个错误是无法被检测和修复的。10^14bit,大约相当于12.5TB的数据,也就是说,每读取12.5TB的数据,就有可能产生一个错误的读取。而对于目前现在硬盘的容量越来越大,4TB,6TB硬盘的价格越来越低,这种现象会越来越严重。

在RAID5中,当整个集群有一块硬盘出现损坏需要替换时,需要进行重建,重建时,需要读取其他硬盘的数据,计算出替换的那块硬盘的数据,在重建过程中,除了需要考虑重建的时间之外,还要考虑的就是URE的影响,如果集群的容量足够大,比如超过10TB,那么,其实是有很大的概率出现读取错误的,而一旦读取出错,则RAID的重建就会失败,基本也就意味着,数据能恢复的可能性变得相当低了。所以在使用RAID5时,就需要考虑重建的问题。

不过对于企业级的硬盘,URE普遍能做到1×10^-15,就意味着大约能读取125TB的数据,容量有比较大的提升,对于SSD,这个值会更加优秀,有些SSD能达到1×10^-17甚至1×10^-18,能提供更好的数据安全性。

所以,稳定点的话,还是RAID10吧。