O_DIRECT与gcsfuse的go程序中实现内存页面对齐

什么是O_DIRECT?

open() 时传 O_DIRECT,之后该 fd 的 read()/write() 走"直接 I/O"------数据在用户缓冲区与设备/文件系统之间直接搬运,不经过内核页缓存。

其文件偏移(offset)、传输长度(length)、缓冲区起始地址(buffer)都要对齐。若任意一条被违反,read()/write() 都会返回 EINVAL

为什么O_DIRECT必须对齐?

页缓存路径为什么没这个要求?因为页缓存里的页天然页对齐,写回时由内核整理成规整请求。而 O_DIRECT 把用户的任意地址缓冲直接组装进 bio 提交给块设备:

块设备的 DMA 引擎以扇区(512B)/逻辑块为最小搬运单位;

一个 bio 必须由整扇区描述(起始扇区、扇区数);

若 offset/length/缓冲地址不是扇区整数倍,请求无法无歧义地映射到设备扇区,块层也无法拆分或修补(DIO 语义要求"用户缓冲即设备数据",不做读-改-写)。

所以内核的立场是:做不到精确对齐就干脆拒绝(EINVAL),而不是悄悄帮你补。

gcsfuse如何处理O_DIRECT的场景

Go程序在通过make申请内存时,不会保证返回地址对齐,分配器可能返回任意地址。例如:

go 复制代码
buf := make([]byte, 4096)
uintptr(unsafe.Pointer(&buf[0])) % 4096  // 可能不为 0

有的场景下业务需要内存地址页面对齐的buffer。例如Linux O_DIRECT对缓冲有硬性对齐要求:绕过页面缓存直接与块设备/网络层做DMA,要求缓冲区地址、文件偏移、传输长度三者都对齐到逻辑快大小(安全标准做法是对齐到页大小4096)。违反任意一条,read()/write()都直接返回EINVAL。

因此凡是做O_DIRECT I/O的地方都需要实现"内存页对齐地址"的功能。例如如下gcsfuse中的实现:

go 复制代码
// GetMemoryAlignedBuffer creates a buffer([]byte) of size bufferSize aligned to
// memory address in multiple of alignSize.
func GetMemoryAlignedBuffer(bufferSize int64, alignSize int64) (buffer []byte, err error) {
	if bufferSize == 0 {
		return make([]byte, 0), nil
	}
	if alignSize == 0 {
		return make([]byte, bufferSize), nil
	}

	// Create and align buffer
	createAndAlignBuffer := func() ([]byte, error) {
		newBuffer := make([]byte, bufferSize+alignSize)
		l := int64(uintptr(unsafe.Pointer(&newBuffer[0])) % uintptr(alignSize))
		skipOffset := alignSize - l
		newBuffer = newBuffer[skipOffset : skipOffset+bufferSize]

		// Check if buffer is aligned or not
		l = int64(uintptr(unsafe.Pointer(&newBuffer[0])) % uintptr(alignSize))
		if l != 0 {
			return nil, fmt.Errorf("failed to align buffer")
		}
		return newBuffer, nil
	}

	// Though we haven't seen any error while aligning buffer but still it is safer
	// to attempt few times in case alignment fails.
	for range 3 {
		buffer, err = createAndAlignBuffer()
		if err == nil {
			return buffer, err
		}
	}
	return buffer, err
}

其本质上是把make多分配的alignSize字节作为"缓冲垫",从实际起点挪到下一个页边界开始用:

  1. 多分配alignSize字节,保证整个bufferSize + alignSize区间内必然存在一个从对齐地址开始的bufferSize长窗口--无论base落在对齐周期的哪个相位,都能在[base, base+alginSize)内找到下一个对齐点。
  2. 计算跳转量。l = base mod alignSize,获取到当前make出来的buffer的内存地址,mod 对齐大小,则可以获取当前buffer内存地址的页内偏移。注意当l == 0时(即本身已经对齐),会整段跳过--正确但浪费一个周期。
  3. 获得跳转偏移:skipOffset := alignSize -l 。
  4. 切割已申请的buffer,通过在调整逻辑地址的方式来实现"只使用已经被对齐的内存页"的效果:newBuffer = newBuffer[skipOffset : skipOffset+bufferSize]
相关推荐
谢亮_vipxieliang20 分钟前
Go map与结构体的正确使用
开发语言·golang·哈希算法
H.莓飛27 分钟前
【C++】命名空间、缺省参数、函数重载与引用
linux·开发语言·c++·visual studio
xxwl58538 分钟前
数据结构知识点和代码实现总结(C语言实现)
c语言·开发语言·数据结构
microrain1 小时前
先应答,再入库:SagooIoT 接入 GB/T 32960 的四层宿主改造
物联网·golang·开源·sagooiot
llqbzllll2 小时前
Spring AI 工具调用不是反射一下就结束:用 2.0.1 跑通失败恢复与调用上限
人工智能·后端
狼爷2 小时前
Rust/Go/Java/Python/PHP 大比拼:负载下后端框架到底差多少?
java·后端·编程语言
mantou1323 小时前
我给 AI Agent 做了个「油猴」:让 Claude Code / Codex 直接用你已登录的浏览器
前端·javascript·后端
程序员老赵3 小时前
Docker 部署 DeepSeek Harness:轻松搭建局域网里的 AI Agent 平台
后端·ai编程·deepseek
YIAN3 小时前
实战|用 DeepSeek + SQLite 从零搭建轻量 Text2SQL 查询助手
后端·sqlite·deepseek
王中阳Go3 小时前
自己摸了 2 个月零 offer,补底子只用了 3 块:Go 后端转 AI 最难的不是技术
后端·agent·ai编程