在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被我放在了同一台机器上，实际部署的话，还是要放在不同的机器上保持高可用。
一个简单的内核Socket Client例子，实现一个简单的客户端，发送一些数据到服务端，并从服务端接受数据打印到dmesg。在Linux 4.8.13内核测试通过。
经常会在日志，或者其他地方遇到类似 '\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吧。