LWN: 数据库开发者对Linux kernel的要求

点击上方蓝色“Linux News搬运工”关注我们~

Better guidance for database developers

By Jake Edge

LPC

在2019 Linux Plumbers Conference (LPC)会议内第一次的Databases microconference会议上，两位为不同数据库系统工作的开发者针对Linux环境下的开发工作提出了类似的抱怨意见。Richard Hipp，是SQLite数据库的创始人，而Andres Freund是来自PostgreSQL项目，他们都觉得Linux kernel里缺少I/O接口行为的明确定义，尤其是在某些特殊情况下。会议过程表明kernel跟user-space的开发者需要多多交流。

SQLite

Hipp简介了一下SQLite（他的发音是“ess-kyew-ell lite”），与其他数据库系统有什么区别，要点可以参见他的ppt（https://sqlite.org/lpc2019/doc/trunk/slides/sqlite-intro.html  ）。他的主要话题是“SQLite开发者希望Linux文件系统开发者知道的一些信息”。

SQLite到处都在用，甚至我的索尼相机里都可能有使用SQLite。总之汽车、手机、电视等等都有用到。世界上有25亿安卓手机，每台里面都有至少200个SQLite数据库在用。每台手机每天估计有超过5GB的SQLite I/O操作。

SQLite跟其他数据库系统最大的不同，就是它其实是application里面编译进去的一个库文件。没有服务器线程。大多数数据库都是为数据中心设计的。SQLite是运行在网络的端侧的，直接用一个文件存放整个数据库，在日志文件系统上可以支持atomic commit功能。SQLite没有配置文件，会自动在运行时检测系统的能力。

同时可能会有多个进程同时访问数据库，毫无关联。通常数据库可以有三种机制来提供atomicity, consistency, isolation, durability (ACID，原子性，一致性，隔离性，耐久性）保证。最常见的是rollback journal(回退日志)，这个方法最慢。还有write-ahead log，会快一些，如果已知数据库文件不是放在一个网络文件系统上就可以用这个方法，不过很难确认是否真的不在网络文件系统。

一位听众说可以用statfs()来确认文件系统类型，Hipp说是可以，不过SQLite就得维护一个各种网络文件系统的列表。通常SQLite是静态链接到application里的，很难更新这个列表。

SQLite也可以用F2FS的atomic write能力。这是Linux特有的方案，不过确实非常快。他听说如果把一台旧手机的ext4文件系统格式化成F2FS的话，用起来就感觉是一个全新手机一样。可以用一个ioctl()接口来确认这个功能是否可用。要是能有一个通用一点的方法来确认，那就更好了。

会议中他提到了几个具体的问题，其实还有很多其他问题。首先他提到，没有一个可靠方法来查询文件系统属性。例如创建文件并写入数据后，调用fsync()，那么你是否需要再打开这个文件所在的目录也进行一次fsync()来保证数据确实存入目录了？是不是每个文件系统行为都一致？

内核文件系统开发者Jan Kara说POSIX标准要求使用目录的fsync()来确保数据存储完成，通常来说，文件系统开发者除了POSIX的规定以外不愿意多做保证，否则就会束缚他们自己。世纪来说，ext4会自己进行目录的fsync()操作，因此在ext4系统上并不需要额外的fsync()操作，至少目前是这样。SQLite会永远都确保对目录进行fsync()，如果没有并发访问的话，这个动作倒也耗时不多。Kara提供的这些信息，对Hipp来说，恰恰就是他想知道的信息，并且是来自权威人士的。

Hipp还想知道SQLite是否需要告诉文件系统文件的哪一部分没有被用到。今后这一部分可能会被用到，不过至少在某些时候这部分只是被分配出来，其中的数据SQLite完全不关心。有人觉得是不是文件系统能利用这个信息来对SSD进行TRIM操作，不过通常人们觉得没有这个必要。Kara说，除非没用到的这些部分的大小是GB级别，否则用不着关心它。

PostgreSQL

Freund一上来就抱怨说，在PostgreSQL里面进行durability handling非常困难：每个Linux文件系统都有不同的行为。大多数系统调用都没有描述出错之后的详细行为。比如fsync()的错误值直到Linux 4.13才能正常报出来，不过目前文档里还是没有描述错误值的含义，以及是否需要application重新发起。

Kara基本赞同他的说法，他说标准里面只定义了正常情况的行为。POSIX也没有也没有定义这些durabiilty方面的信息，他跟Freund都有同样的烦恼。

Freund接着描述了另一个文档问题：durability操作，例如sync_file_range()都会附有很吓人的警告（"This system call is extremely dangerous and should not be used in portable programs ..."），看起来根本不希望应用开发者使用一样。但是如果应用开发者碰到性能问题了，得到的建议经常是去用sync_file_range()。Kara说这个警告信息是因为某些文件系统会能确保存储这一段数据，但是有些文件系统就不能保证。Freund觉得这样的话，应用开发者就不得不仔细研读kernel代码才能决定是否可以使用这个函数了。

并且这里的出错行为在各种文件系统、块设备、内核版本上也都各不相同。某一个文件系统上你可能会在I/O error后拿到旧数据，换一个文件系统上就有可能拿到新数据，在NFS上甚至根本不会有错误信息，直到文件被关闭才会发现。应该有个文档描述清楚应用程序应该根据什么信息来判断出具体的行为。没有标准的话，写出来的代码行为肯定会有差异。

一位听众问道：“你希望描述得有多深入呢？” 文件系统开发者受限于块设备层开发者，而后者又受限于硬件设备本身。各种存储设备都可能会导致行为差异。

Freund说他们正在寻找这些不同行为中的共同点。比如，目前在一个"thin-provisioned（精简配置的） block device"上，可能某个系统调用就会返回一个文档中没有描述的ENOSPC错误。他其实觉得只要文件系统和块设备层的错误信息只要能保持一致就好，并不需要Linux需要隐藏设备的差异性。

他觉得，出错之后的行为还是要有文档描述。如果fsync()失败了，然后重新发起，那么会有什么后果？此前的sync操作是会重试，还是会直接丢弃新数据？后面这种行为他们也观察到过。应用开发者不得不在Linux kernel邮件讨论里面搜索这些信息。

除了错误情况下需要文档外，还需要有文档能描述一下如何安全的完成某件工作，有什么最好的办法。目前只能是猜测着来做，或者需要跟内核开发者喝酒的时候聊清楚。喝酒是很好，不过大家天各一方，也没法经常这么解决啊。

比如说，没有文档描述怎么能确保数据存储成功。应用开发者的各种实现方式，都有内核开发者抱怨。如果会导致性能下降，内核开发者会说这个application做得保护太过了；不过如果有人担心数据丢失，那么就会抱怨保护还不够。大家的观点让人无所适从。

还有个例子是如何能让文件rename操作确保原子性，怎么能在磁盘上保证这一点？某些文件系统开发者说需要对文件本身以及它所在的目录进行fsync()，然后再做rename()，然后再对新文件和所在目录进行fsync()。这个步骤是否必要，也经过了很多争论。不过Tomas Vandra说PostgreSQL经过大量测试之后，最终还是按照这个步骤做了，终于解决了那些数据丢失问题。

Kara赞同Freund说到的文档确实不完整。他的建议是在linux-fsdevel mailing list上提问，确保问题信息描述清楚。相关的回复邮件就可以被整理成文档放到kernel的Documentation目录下去。Kara也觉得atomic rename()的这个问题确实挺可惜的，建议应该发到mailing list上来讨论。

一位听众问Freund是否能接受知道一个最小集合的共同行为列表，因为多种文件系统对同一个问题会有多种回答。Freund说这样也行，毕竟针对某些性能敏感的代码，也是可以针对文件系统使用针对性的代码。在回答其他问题的时候，Freund说他最主要想知道在哪些error情况下需要retry重试来增大成功概率。

从这些讨论里来看，数据库开发者（可能还有其他user-space应用开发者）都需要找到更有效的方法来跟内核开发者合作，反之亦然。这次的microconference是第一次，后续还需要跟多的邮件讨论，来创建更好的文档。首先应该来提供一些引导教会应用开发者如何能确保数据安全，包括文件内容和metadata的一致性。

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Lisbon for LPC.]