微软为macOS开发大型Git仓库虚拟文件系统

编辑｜张婵

微软首要项目负责人Saeed Noursalehi于 3 月 15 日发博客称微软在开发 macOS适用的大型Git仓库虚拟文件系统（GVFS) 上取得了不错的进展。

背景

1. 什么是GVFS

GVFS (全称Git Virtual File System，即Git虚拟文件系统）是微软开发的开源系统，能使Git在企业级别运行，用于使用和管理大型Git仓库。

2. GVFS如何工作

GVFS将Git仓库下的文件系统虚拟化，这样即使文件实际并不存在于磁盘上，Git工具也能看到正常显示的存储库。GVFS只根据需要在第一次打开文件时进行下载。

GVFS还管理Git的内部状态，只考虑被访问的文件，而不必检查仓库中的所有文件，这样就能确保status和checkout等命令的速度。

3. 为什么要用GVFS

Git在企业级存储库中运行有点吃力。当存储库中有数以百万的文件时，克隆等操作就会慢得像蜗牛一样，甚至像获取存储库状态这样简单的操作都需要等待。

GVFS由微软的Visual Studio Team Services团队创建，专门用于处理微软自己代码库的规模问题。

借助GVFS，Git和Visual Studio Team Services的开发人员即使在使用300 GB（350 万个文件）储量的Windows操作系统时也能保持高效工作。

使用GVFS，微软团队能够在比现存任何仓库都要大几个数量级的Git仓库中工作。

GVFS目前仅支持Window 10版本。现在，微软正在探索如何将GVFS搭建在其他平台上，并且已经在macOS适用的GVFS原型设计上取得了不错的进展。

Windows版GVFS主要由三大块组成：

Git补丁，使GVFS能在虚拟文件系统上高效运行 ;

文件系统过滤驱动，能拦截一些文件系统操作，并询问一个用户态进程如何响应目录枚举和文件内容；

用户态进程，知道如何翻译Git仓库的状态来响应文件系统查询，以及如何响应文件系统事件来修改Git仓库状态。

感兴趣的话可以通过以下链接获取更多相关信息以及代码内容：

https://www.visualstudio.com/learn/gvfs-architecture/

https://github.com/Microsoft/GVFS

其中第一项和第三项并不固有地绑定在任何操作系统上，但是第二项和特定操作系统、文件系统以及驱动模型紧密相关。这一项需要为每个操作系统重写，现在微软就在考虑为macOS做开发。

设计方法

Windows系统有一个文件系统过滤驱动的概念，它能堆叠到现存文件系统驱动上并修改系统的行为。MacOS不支持以这种方式堆叠驱动，所以微软探索了别的方法，最终确定采用Kauth内核扩展机制来达到相似的效果。

当应用程序访问文件或目录时，内核需要判断当前用户是否有权限访问该对象。Kauth允许一个自定义内核扩展（kext) 来注册这些授权请求，并且能决定用户的权限，这样就提供了如下的一些功能：

阻止应用程序枚举目录，这样就能为目录子类填入占位符文件／目录。这能实现按需动态枚举文件系统结构；

阻止要读取文件的应用程序，从而填入其内容。这能实现按需下载文件内容；

发现用户修改文件的行为，从而通知Git这些文件可能是“脏”的；

拒绝一些特定操作，例如删除特殊文件或来自文件系统爬行器的请求（如果不拒绝可能会下载整个虚拟文件系统，打断按需加载的尝试）。

要使所有这些都能工作，微软建立了占位符目录 （placeholder directories）和占位符文件（placeholder files）的概念。通过在目录或文件上设置文件标志，使其成为占位符，kext就能快速检查虚拟节点（vnode）是否为需要担心的虚拟项。如果不是，kext迅速返回，以避免给系统IO带来不必要的开销。

在建立一个新的虚拟化root的时候，先创建一个空的占位符目录，磁盘中没有子类。kext (GvKext)首次接到授权枚举该目录的请求时，会阻止这个枚举请求，并通过端口给用户态进程（GVFS）发送一个消息，要求它在磁盘上给该目录的子类写出占位符条目。一旦这些子占位符被写下，GVFS就会向 GvKext发送消息，告知它可以取消阻止枚举的请求。然后应用程序完成枚举，不会注意到该目录有什么特殊之处，除了稍微有点延迟。

类似地，只要GvKext收到授权读取文件的请求，都会检查文件是否仍为空，阻止IO，并要求GVFS填写文件的内容。一旦内容可用，GVFS会向GvKext发送消息，GvKext便不再阻止读取。

原型结果

目前的原型GVFS实际上并没有对Git仓库做任何事情。它现在所做的只是镜像磁盘上现有的物理文件夹，将其作为虚拟文件夹进行投影。这个简单的步骤能够验证通过构建Kauth kext来虚拟化文件系统的方法，并实现两个关键目标：

应用程序兼容，尤其是对构建工具

Hydrated files的访问性能（hydrated files是微软使用的概念：云文件不占据磁盘空间，只有在访问的时候被下载。hydrated files指已经下载的文件。）

为了验证这些目标，微软克隆了一些庞大而复杂的Mac代码库，然后创建了它们的虚拟投影，并在虚拟投影之上构建代码库。这帮助他们找到并修复了一些有趣的bug，但是现在他们已经可以在虚拟文件夹之上可靠地传递构建了。

另外，微软团队已经能够证明第二个完全构建耗时仅为非虚拟化文件夹上一个完整构建的10%。这个时间仍需努力缩短，但对于非优化的原型实现来说，数据在10％以内已经非常鼓舞人心了。

这里提供一个参考数据：使用基于FUSE的原型，对水合文件的访问开销从未低于150%。

敬请期待……

目前微软刚刚构建了kext的原型版本。接下来还有很多工作要做，以使其功能全面且强大，性能卓越，可以诊断并且生产准备就绪。微软还计划在GVFS用户态代码库中进行清理和重构，以允许使用.NET Core在Mac上运行相同的代码。这些工作将在未来几个月内开展，一些勇敢的早期使用者即将开始使用并向微软发送反馈。

微软团队计划在公开库中发布macOS适用的GVFS的所有代码，还计划将开发流程改为公开编写代码，而非偶尔在公开库中增加代码。更多信息将很快提供。

活动推荐

随着 AI、Big Data、Cloud的逐渐成熟，FAAS、CAAS等技术的兴起，以及被运维业务的多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，AIOps智能运维、大数据运维、ChatOps、SRE、Chaos Engineering、微服务与容器运维等新技术和方向应运而生，它们一方面把最前沿的技术结合到运维中来，一方面在人员角色、领域范围、文化等方面又有了很多扩展，让传统运维有了翻天覆地的变化。