Kernel

SMB协议 vs TCP的延迟ACK特性

| Kernel | #SMB | #TCP | #delayed ACK | #networking | #Windows

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

参与评论

针对桌面系统的一个ULE调度器tunable

| Kernel | #FreeBSD | #kernel | #ULE scheduler | #performance | #desktop

在 /etc/sysctl.conf 中加入：

kern.sched.preempt_thresh=224

然后用 /etc/rc.d/sysctl start 或重启系统令其生效。

系统默认的值是 80，表示只有新优先级 < 80 时才允许抢占；224 表示非空闲线程均可以进行抢占。这样做的结果是系统会产生更多的切换，从而改善响应时间（牺牲吞吐量）。对桌面系统来说，这种设置是很有用的。

参与评论

ZFS dedup初步测试

| Kernel | #ZFS | #deduplication | #storage | #performance | #FreeBSD

最近做一个存储的项目，顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28，硬件是 Atom D510 配合 4G 内存。

阅读全文…( 本文约 667 字，阅读大致需要 2 分钟 )

折腾了一下 neptune 上的 ZFS

| Kernel | #ZFS | #FreeBSD | #4KiB sectors | #AF drives | #performance | #sysadmin

我一直是非常反对重装系统的。从技术上说，今天的折腾并不算是重装系统，不过因为把机器上所有的数据（是的，文件系统全部都拆掉重建了）都重写了一遍，所以还是算做了一次吧。

缘起

在采购 家里的路由器 的时候，选择了 WD 的 AV-25【1】 系列硬盘。我选的那款硬盘使用的是新式的 AF （4kiB扇区）格式。

FreeBSD 使用的主流文件系统 UFS 和 ZFS，以及 ahci(4) 驱动都 直接支持 4kiB 扇区。但是，目前市面上的AF硬盘，为了与先前的 BIOS 和操作系统（主要是 Windows XP）兼容，对于 ATA IDENTIFY 的回应，原先返回扇区尺寸的位置变成了逻辑扇区尺寸，这种做法俗称512e，即硬盘通过固件或其他方式模拟山区尺寸为512字节，并处理相关的回写操作。

以512字节为单位进行读写时，在AF格式的硬盘上是低效的。FreeBSD的 ahci(4) 驱动和对应的 ada(4) 驱动会设置 stripesize 以反映驱动器采用的实际物理扇区尺寸，但文件系统并不直接识别这个尺寸。

对于 ZFS 而言，其扇区尺寸是在创建时以 ashift 值写死的，目前在命令行没有办法指定这个值，也不能在创建 ZFS 之后修改。如果修改内核令其使用 GEOM 的 stripesize 来产生 ashift，对 AF 硬盘则会出现内核得到的 ashift 比先前已经存在的 ashift 大，从而导致 ZFS 无法识别的问题（如果创建 ZFS 时已经使用了更大的 ashift 则没有关系）。因此，必须想办法让 ZFS 在创建时就知道扇区尺寸是 4KiB。

FreeBSD 5.3-RELEASE 时新增了一个调试用的 GEOM class —- gnop。可以用它来封装其他 GEOM 对象，并改变扇区尺寸，方法是 gnop create -S 4096 /dev/gpt/store （此处 /dev/gpt/store 是一个按 4k 对齐的 GPT 分区的 label）。gnop会产生一个新的设备节点，/dev/gpt/store.nop，其向系统汇报的扇区尺寸是我们指定的 4096 字节，而不是驱动器汇报的逻辑扇区尺寸 512 字节。

使用这个设备节点创建的 ZFS 就会采用正确的 ashift 值了。

使用 zdb -C pool名字可以检查 ashift 值：对于扇区尺寸为 512 字节的 zpool，其 ashift 是 9，而我们希望的 ashift 值是12。

gnop节点在系统重启以后会消失，但 ZFS 会记住 ashift，因此并不会导致问题。此处也可以 zpool export，gnop destroy /dev/gpt/store.nop 然后再 zpool import 来验证。

经测试，ZFS在知道正确的扇区尺寸以后，持续写操作的性能可以提高至少一倍。

阅读全文…( 本文约 2314 字，阅读大致需要 5 分钟 )

对齐操作和非对齐操作

| Kernel | #alignment | #performance | #kernel | #storage | #C/C++

操作是否对齐是一个简单而容易忽略的性能（有时是可靠性）问题。对齐主要是指读写操作不产生不必要地跨越存储设备上原生存储单元的访问，这里的存储单元说的是在访问路径上的任何设备，它可以是外存，也可以是内存，甚至是CPU附近或内建的快取缓存，等等。

阅读全文…( 本文约 1145 字，阅读大致需要 3 分钟 )

FreeBSD的textdump

| Kernel | Development | #FreeBSD | #kernel | #debugging | #textdump | #crash analysis

最近遇到一些奇怪的bug，因为是对恢复时间有比较高要求的系统，所以顺便研究了一下用FreeBSD的textdump来代替更早前出现的minidump的方法。

阅读全文…( 本文约 754 字，阅读大致需要 2 分钟 )

RTC 与 NTP

| Kernel | #FreeBSD | #ntp

早期版本的 FreeBSD 有一个问题是，如果使用 ntpd 来校准系统时钟的话，如果长期开机，则在重启之后，时间会差很远，之前一直没仔细研究这个问题。最近突然发现 FreeBSD 8.1-RELEASE 里面没有这个问题了，于是翻看了一下代码和之前的一些邮件才明白是怎么回事，总结一下：

阅读全文…( 本文约 762 字，阅读大致需要 2 分钟 )

FreeBSD上的{rd,wr}msr_safe

| Kernel | #FreeBSD | #kernel | #assembly | #MSR | #x86

这几天改 FreeBSD 的 coretemp(4) 遇到了一个问题。直接使用 rdmsr 的话，如果那个 MSR 不存在，则会触发 #GP(0)，不了解 CPU 型号的情况下直接去杵肯定是不行的。后来翻了一下 cpuctl(4) 的代码发现 FreeBSD 上也有 rdmsr_safe。它的实现并不复杂（ sys/amd64/amd64/support.S）：

阅读全文…( 本文约 364 字，阅读大致需要 1 分钟 )

文件系统与大扇区

| Kernel | #GEOM | #offset | #sector | #storage | #stripe size

大扇区（超过旧式标准的512字节扇区）是改善硬件工艺或访问方式以后的一种直接提高存储密度的方法。对于磁介质来说，其盘片被分成若干的磁道（通常是同心圆）、每个磁道分成若干的扇区或称扇段，扇区是磁盘读写时的最小操作单元。对于基于闪存的存储设备而言，扇区则是一种模拟传统磁盘的概念。

阅读全文…( 本文约 1218 字，阅读大致需要 3 分钟 )

SU+J

| Kernel | #file system | #journalling | #Soft Updates | #UFS

Jeff Roberson 下周左右将会正式发表对于 UFS 的一项改进，为 Soft Updates 加入 Journal-ling，从而简化其恢复逻辑，并消除对 fsck 的依赖。

目前常见的保持元数据一致性的方法有四种：最原始的、将元数据以同步方式写盘的方法，性能非常差；常见的文件系统中使用的元数据回写日志（如ext3），缺点是无法检验日志本身的正确性，而且元数据需要写入两次因此对性能有潜在影响；Soft Updates，缺点是需要运行fsck来释放资源泄漏，而这个操作很耗时，且实现本身比较复杂；Copy-on-Write，在WAFL和ZFS中采用的技术，随着硬盘的淘汰随机存取时间不再是性能瓶颈，应该是未来的发展趋势，目前的缺点是会导致产生较多碎片。SU+J结合了Soft Updates和Journalling的优点，即，使用Soft Updates来确保写到磁盘上的数据的一致性，而使用Journalling来确保资源泄漏能够迅速回收，从而消除了fsck的必要性。

阅读全文…( 本文约 598 字，阅读大致需要 2 分钟 )