dd 之速度实时统计

dd命令正常情况下，完成之后才显示完成了多少，速度是多少；如果你感觉dd时间很长了，想知道啥时候能完成，可咋办？

man 手册中有说明： 给dd一个 USR1 信号就会打印统计信息到标准错误

这里想强调一个问题： 不管学啥，要多看文档，养成看文档的好习惯；从文档上学到的是“系统化”的东西； 从百度、google看到的都是零碎的东西

dd查看磁盘的mbr：

qemu 编译

qemu的编译是比较简单的： https://www.qemu.org/download/#source

qemu 的编译逻辑是：

如果你编译环境上有相关功能的库和开发包的支持，则编译出来的qemu就支持该功能，如果没有就自动不支持；所以，你基本不需要明确开启指定功能的选项，但是，如果你想明确禁止支持某功能，可以明确通过选项来禁止

 

我的环境下，安装了下面这么多包，enable了很多支持

 

pid namespace

The namespace init process
The first process created in a new namespace (i.e., the process
created using clone(2) with the CLONE_NEWPID flag, or the first child
created by a process after a call to unshare(2) using the
CLONE_NEWPID flag) has the PID 1, and is the “init” process for the
namespace (see init(1)). A child process that is orphaned within the
namespace will be reparented to this process rather than init(1)
(unless one of the ancestors of the child in the same PID namespace
employed the prctl(2) PR_SET_CHILD_SUBREAPER command to mark itself
as the reaper of orphaned descendant processes).

cgroup 审计策略

内存子系统

场景：

当你把一个已经占用了1GB内存的进程转移到一个新的cgroup后，新的cgroup看到的该进程使用的内存大小会是多少呢？

memory.max_usage_in_bytes  和 memory.usage_in_bytes 都不会将这1GB计算在内的，只有该进程继续申请内存才会计算新申请的内存。

同样，如果把一个占用内存很多的进程从cgroup中移出来，memory.max_usage_in_bytes  和 memory.usage_in_bytes 应该也不会被更新

Process Number Controller

  1.  pids.current 可以大于 pids.max
    1. 当cgroup中进程数量达到最大时，cgroup并不“阻止”从其它cgroup中移动一个进程到该cgroup中；只是说不允许在该cgroup中fork、clone新的进程或线程
  2. pids.current包含所有子孙cgroup中的进程(和线程）
  3. 当cgroup对进程数量不限制时，pids.max 不是0（零）也不是-1，而是字符串max😓

docker 之磁盘限额

docker-ce-17.07.0 版本开始支持overlay2的磁盘配额，该版本 8月29号release了，现在可以使用edge版本：

https://download.docker.com/linux/centos/7/x86_64/edge/Packages/docker-ce-17.07.0.ce-1.el7.centos.x86_64.rpm

 

overlay2的配额限制是有条件的：

  1. 基于xfs文件系统(如果不开启配额的话，ext4上也能支持，如果内核版本够高的话，btrfs也能支持)
  2. xfs文件系统挂载时使用pquota选项(pquota和gquota 不能同时出现)
  3. xfs 格式化时需要ftype=1，用于enable d_type

 

xfs的pquota是个啥东西： https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/xfsquota.html

 

XFS quotas are enabled at mount time, with specific mount options. Each mount option can also be specified as noenforce; this will allow usage reporting without enforcing any limits. Valid quota mount options are:
  • uquota/uqnoenforce – User quotas
  • gquota/gqnoenforce – Group quotas
  • pquota/pqnoenforce – Project quota

注意：

pquota和gquota 不能同时出现

  • uquota： 强制限制，绝对不能超限
  • uqnoenforce：可以超限，但是会贴罚单

 

如果是kickstart 安装的系统，用如下命令：


mkfs.xfs 还有很多选项，专门研究存储的话，还是要了解的

参考： http://foxhound.blog.51cto.com/1167932/1841487

docker-ce-17.07.0 关于xfs上的overlay2存储驱动的磁盘限额，使用效果如下：

注意：

  1. –storage-opt时， 使用的是size，而不是overlay2.size；关键是多处文档描述的都是overlay2.size=1g，而实际上却不识别overlay2.size，识别的却是size
  2. 做磁盘限额的时候，基础镜像的大小显然没有计算在内； 不做磁盘限额的时候，显示的是整个overlay文件系统的使用情况
  3. 据说daemon.json 中也是可以定义存储选项的，但是测试发现不管使用overlay2.size还是size都不报错，也都不生效（但是源码上确实都是overlay2.size呢）
  4. docker info中不显示默认的存储配额
  5. 关于存储选项： overlay2.override_kernel_check， 文档 要求必须设置为true，实际情况是：
    1. 如果设置为true，docker会帮忙检查内核版本够不够高，不够高就直接报错了
    2. 如果设置为false，docker依然会帮忙检查内核版本够不够高，不够包就记录一个警告日志

阿里云提供的centos7镜像的文件系统类型似乎都是ext4的

并非所有的D状态的进程都是kill不掉的：

docker 的磁盘限额是可以通过xfs_quota 查看到的（kernel内核版本要求4.6以上才能查看到，小于4.6的内核版本上不是不支持限额，只是通过xfs_quota 看不到而已）