Turso AgentFS：面向 AI Agent 的文件系统设计分析
说明: 本文介绍的 Turso AgentFS，与贾扬清新公司 Intent Lab 推出的同名 AgentFS 不是同一个项目。本文并不分析 Intent Lab AgentFS，而是分析搜索资料时意外发现的开源项目 tursodatabase/agentfs。 事情的起因是最近看到一篇关于 Intent Lab 的报道。报道里提到 Intent Lab 推出了一个名为 AgentFS 的分布式文件系统，我去搜索相关资料时，意外找到了 Turso 开源的同名项目 AgentFS。 Turso AgentFS 将文件、状态和工具调用记录存入一个 SQLite 数据库，并在此基础上提供虚拟文件系统、Overlay 工作区和挂载能力。 本文不会重复官方已经提供的安装和基础使用教程，而是结合 AgentFS v0.6.4 的代码与 Specification v0.4，分析它的项目定位、数据模型、隔离方式、适用场景和当前边界。 一、项目描述Turso AgentFS 的核心不是搭建一个新的远程文件服务，而是把 Agent 运行时需要保存的内容放进一个 Turso 兼容的 SQ...
Ceph Pool 使用 EC 的条件与限制
Ceph 的 Pool 可以采用 replicated（副本）或 erasure-coded（纠删码，简称 EC）两种数据保护方式。与多副本相比，EC 通常能以更少的冗余空间保护数据，但能否用于某个 Pool，还取决于该 Pool 中的对象需要执行哪些 RADOS 操作。 以 Ceph v20.2.0 为例，EC Pool 不支持 RADOS OMAP，因此依赖 OMAP 的 CephFS Metadata Pool、RBD Image 主 Pool 和 RGW Bucket Index Pool 必须使用副本类型。用于保存数据的 Pool 则可以在满足相应条件后使用 EC。 本文基于 Ceph v20.2.0 的源码，先介绍 EC 的基本原理与 Ceph 中的配置方式，再分析 EC Pool 不支持 OMAP 的原因及支持 OMAP 所需的改造，最后分别梳理 CephFS、RBD 和 RGW 的 Pool 布局与 EC 使用限制。 一、EC 基本概念1.1 编码原理纠删码用数据片段（data chunk）和计算得到的校验片段（coding chunk）共同保护数据。与多副本相比...
CephFS RADOS 对象数据解析
本文从 RADOS 对象层解析 CephFS 的 metadata_pool 与 data_pool 布局，梳理目录分片、基础 inode、MDS journal、表对象、文件数据对象及 0 号对象 xattr/omap 的命名、内容与排查命令，帮助理解 CephFS 元数据和数据如何落盘。 一、总体结构CephFS 将“文件内容”和“文件系统命名空间”分离存储： flowchart LR subgraph Client["CephFS client"] VFS["读写 /a/b/file"] end subgraph MDS["MDS"] Cache["目录树、inode、会话、日志"] end subgraph MetaPool["metadata_pool"] DirObj["目录分片对象<br/>ino.frag"] InodeObj["基础 inode 对象<...
ProxyAssistant - 强大的浏览器代理管理扩展
ProxyAssistant 是一款功能强大的浏览器代理管理扩展，支持 Chrome、Firefox、Edge 等多款浏览器，支持多场景管理，帮助用户轻松配置和切换网络代理。作为一款开源的浏览器扩展，ProxyAssistant 凭借其丰富的功能特性、优秀的用户体验和完善的多语言支持，已成为众多用户管理网络代理的首选工具。 一、项目概述1.1、项目简介ProxyAssistant 诞生于对高效代理管理工具的需求。作为一款现代化的浏览器扩展，它采用了最新的 Manifest V3 规范，充分利用了现代浏览器提供的各种 API，为用户提供了一个界面美观、功能完善、操作便捷的代理管理解决方案。项目采用原生 JavaScript 和 jQuery 开发，是一款成熟稳定的代理管理工具。 该扩展的核心设计理念是”简单易用，功能强大”。无论是需要频繁切换不同代理服务器的用户，还是需要为不同网站配置不同代理规则的高级用户，ProxyAssistant 都能满足其需求。同时，项目完全开源，采用 MIT 许可证，任何人都可以自由使用、修改和分发。 项目地址：https://github.com/bu...
Ceph 命令注册及执行流程
一、介绍本文的内容基于 Ceph v20.2.0 版本进行分析。 分析 ceph -h 的输出信息可以看到，其支持两种类型的命令，分别是 Local Commands 和 Monitor Commands。其中 Local Commands 比较典型的就是 ceph daemon {type.id|path} <cmd> 命令，用于直接和本地组件的 socket 进行通信，执行一些命令。而 Monitor Commands 则是将相关命令发送给 Monitor，有些是由 Monitor 自身处理该命令并返回，也有一些只是经由 Monitor 中转给其他组件执行（比如 ceph tell osd.0 * 等命令）。 对于 Local Commands，我们分析每个组件（MON/MGR/OSD/MDS）的 admin socket 命令的注册和执行流程； 对于 Monitor Commands，我们分析 二、Local Commands 分析对于本地的命令，我们仅分析每个组件的 admin socket 的命令注册和执行的流程。注意：虽然...
Ceph 日志实现分析
Ceph 服务器日志系统通过宏定义和线程机制实现高效日志记录。首先，通过枚举和数组定义日志子系统（如osd、mon），并利用 dout 、 dendl 等宏展开为条件判断和日志组装代码。服务启动时，global_init 初始化上下文并创建独立的 log 线程作为消费者。日志输出时，生产者通过宏替换生成实际代码，判断日志级别后，将日志条目提交到队列，若队列满则阻塞。 log 线程从队列取出日志，根据配置将日志输出到文件、 stderr 、 syslog 、 graylog 或 journald 等多个目标，支持灵活的日志级别和输出控制。整个流程实现了异步、可配置的多目标日志记录。 注意: 以下的分析基于 Ceph V20.2.0 一、服务器侧日志1.1、日志环境准备1.1.1、日志子系统按照 官方文档 中提到的日志子系统的配置。 注意: 在提交日志的时候，只要日志的级别在 max(日志级别, 内存级别) 的范围内，都会提交到日志队列中； 所有提交到日志队列中的日志都会被记录到内存中的 m_recent 环中 (环的大小受限于 log_max_recent 配置)， 以便在需要时...
Ceph 和 LinuxKernel 版本时间对照表
本文提供了一份详细的Ceph、Ceph-client与Linux内核版本对应关系表，涵盖了从2015年至今的月度发布记录。内容包含各版本的具体发布时间、GitHub链接以及三个组件的时间轴甘特图，旨在帮助用户快速查询和规划Ceph部署时所需的内核兼容性。 一、版本时间对照1.1、版本时间对照表 Month ceph ceph-client linux 2011-07 v3.0 2011-10 v3.1 2012-01 v3.2 2012-03 v3.3 2012-05 v3.4 2012-07 v3.5 2012-10 v3.6 2012-12 v3.7 2013-02 v3.8 2013-04 v3.9 2013-07 v3.10 2013-09 v3.11 2013-11 v3.12 2014-01 v3.13 2014-03 v3.14 2014-06 v3.15 2014-08 v3.16 2014-10 v3.17 2...
Ceph 各组件端口使用分析
一、基础信息本文总结了 Ceph 集群及其监控组件的关键端口信息。 Ceph 核心服务（MON、MGR、OSD、MDS）主要监听 6789 、 3300 及 6800-7568 范围内的端口，用于集群通信与管理。其中， MON 使用 6789 （旧协议）和 3300 （新协议）端口； MGR 额外监听 9283 （Prometheus指标）、 8080/8443 （Dashboard）及 8765 （Agent） 等端口。 OSD 在 6800-7568 范围内使用八个端口处理不同通信类型。此外，监控栈组件（如node-exporter的 9100 、 prometheus 的 9095 、 alertmanager 的 9093/9094 、grafana 的 3000 ）也列出了默认端口及修改方法。文中还提供了查看服务状态和修改端口配置的相关命令。 注意: 以下的分析基于 Ceph V20.2.0 相关命令: # 查看网络连接情况lsof -i -P -n | egrep "ceph|node-ex|prome|alertma|grafan"# 查看运行中...
CephFS Inode 编号的申请与释放
一、Inode 编号介绍1.1、编号规则在 CephFS 中 MDS 负责管理所有的 Inode 信息。CephFS 本身支持 多MDS 策略，为了避免多MDS 分配的 Inode 出现冲突，所以 MDS 在分配 Inode 的时候需要使用 RankID 来区分 Inode 的范围。每个 MDS 中限制 Inode 分配范围的函数为 InoTable::reset_state ，每个 MDS 中负责的 Inode 范围为：[(rank+1) << 40, ((rank+1) << 40)) ，即从 (rank+1) << 40 开始的连续 1 << 40 个 Inode 。 MDSRank 起始Inode编号(十进制) 起始Inode编号(十六进制) 结束Inode编号(十六进制) 管辖的Inode数量 0 1,099,511,627,776 0x10000000000 0x1FFFFFFFFF 1,099,511,627,776 1 2,199,023,255,552 0x20000000000 0x2FFFFFF...
Ceph Crimson 设计实现深入解析
Crimson 是 Crimson OSD 的代码名称，它是下一代用于多核心可扩展性的 OSD 。它通过快速网络和存储设备提高性能，采用包括 DPDK 和 SPDK 的顶级技术。BlueStore 继续支持 HDD 和 SSD。Crimson 旨在与早期版本的 OSD 守护进程与类 Ceph OSD 兼容。 Crimson 基于 SeaStar C++ 框架构建，是核心 Ceph 对象存储守护进程 OSD 组件的新实现，并替换了 Ceph OSD 。Crimson OSD 最小化延迟并增加 CPU 处理器用量。它使用高性能异步 IO 和新的线程架构，旨在最小化上下文切换和用于跨通信的操作间的线程通信。 以下分析基于 v19.2.1 进行分析。 一、架构对比Ceph OSD 是 Ceph 集群的一部分，负责通过网络提供对象访问、维护冗余和高可用性，并将对象持久化到本地存储设备。作为 Classic OSD 的重写版本，Crimson OSD 从客户端和其他 OSD 的角度兼容现有的 RADOS 协议，提供相同的接口和功能。Ceph OSD 的模块（例如 Messenger、OSD ...
