问题标签 [journaling]

当写入日志的许多事务之一被损坏时，我试图了解 jbd2 日志的行为。

根据我的理解，对于写入操作，首先进行写入以将数据持久化到磁盘位置，然后将相应的元数据事务写入日志。元数据更新的格式如下 - 1) 事务描述符块 2) 元数据块和 3) 事务提交块。这继续进行多个事务。最后在检查点期间，将与这些事务对应的元数据写入磁盘位置。

我也明白，如果文件系统在检查点发生之前崩溃，则需要在重放期间保持事务之间的顺序。即，如果我们有 3 个事务 T1、T2、T3，它们将按顺序重放。这是为了避免在两个连续事务中发生同一块的覆盖或同一块的删除和后续重新分配的情况。

我的问题是针对一个特殊情况：其中 T1、T2 和 T3 是三个连续的事务，如果 T1 和 T3 维护 M1 元数据块的元数据更改，并且 T2 存储 M2 块的元数据更改。并且 M1 和 M2 完全不重叠，在这种情况下，如果 T2 损坏，是否会丢弃 T3 和所有后续事务？

如何在 IBM i 中分析从 DSPJRN 日志数据库文件中提取的数据？使用命令 DSPJRN 从日志中提取的输出由元数据和原生格式的数据块（文本和二进制数据流）组成。即使可以提取一些信息，我想也有一些规则可以阅读它们，但在我的知识范围内。尚未在文档中看到信息。有人在处理这些数据吗？

文件系统或磁盘驱动程序是否支持文件系统修改栅栏的概念，例如 CPU 或共享内存系统中的内存栅栏？

栅栏是分离内存操作的指令，这样在栅栏事件之后的全局可见内存访问直到所有在它之前的访问才可检测到。

这种功能是否可以有效地用于文件内容修改（和目录修改）？当然，一个简单的解决方案是等到所有写入都写入稳定存储；但是，这会阻塞应用程序，并且如果需要许多同步点，则可能效率低下。此外，当一个大写（包括许多由栅栏隔开的写）满足完全日志系统上的相同约束时，或者当磁盘驱动程序保证最大写是原子的时，它可能会导致许多小的单独写。

是否可以强制文件系统驱动程序使用文件系统访问栅栏对写入进行排序？有没有探索过这个概念？

精确

问题的上下文不是多个进程以一种随意的方式访问相同的文件，而是一个进程将数据保存在数据库中，这样进程的中断（甚至是计算机崩溃）应该只留下一个修改序列（在两个围栏之间）部分写入。

我的客户正在使用 office365，我已经为他们的一些邮箱设置了日记功能。但似乎他们收到的一些电子邮件，还没有发送到期刊邮箱。

我检查了交易规则，但这些都很好。

还有什么其他原因会导致这种错误？

是否有可以检查以查找日志错误的日志文件？

并非所有电子邮件都会发生这种情况，仅某些电子邮件会发生这种情况，因此日志配置应该没有任何问题，对吗？

我只能访问 PowerShell，无法登录他们的真实帐户或管理门户。

我有一个带有相应 AFTER UPDATE 触发器的表，用于更改审计（Oracle 11g）。待审计表Test01：

和表 History01 用于审计更改

当我使用带有 :old 和 :new 别名的列名时，它可以正常工作，例如：

Test01 可以包含更多列，因此我想遍历所有列而不是使用列名。但我不知道该怎么做，因为以下代码不起作用（无法编译）：

有没有办法做到这一点，或者我总是必须使用列名？

是否有任何 python 库可以提供（通用）作业状态日志和恢复功能？

这是我的用例：

1. 接收到开始工作的数据
2. 作业开始处理
3. 作业完成处理

然后，如果进程中止/电源出现故障，我希望能够在1之后重新启动作业。作业将在作业开始时写入日志文件，并在作业完成时标记作业完成。因此，当进程启动时，它会检查日志文件中是否存在未完成的作业，并使用日志数据重新启动未完成的作业（如果存在）。那么有哪些 Python 工具可以解决这个问题呢？（或其他 python 解决方案，对必须完成的关键作业进行容错和恢复）。我知道像 RabbitMQ 这样的作业队列在这种情况下可以很好地工作，但我想要一个不需要外部服务的解决方案。我在 PyPI 中搜索“日志”并没有得到太多。那么有什么解决方案吗？似乎为此建立一个图书馆会很有用，因为在使用难以正确处理的期刊时存在多个问题，但图书馆可以处理。（如多次异步写入、文件拆分和截断等）

我对GitJournal感兴趣，但据我所知，只有移动应用程序。

是否可以在 Mac 上使用它（可能从命令行），如果可以，如何使用？

我们正在构建一个基于 Java 的应用程序，该应用程序使用日志/预写日志 ( WAL )。这个想法是，进入系统的每条消息都在进行任何处理之前首先写入日志。日志充当单一的事实来源，如果失败，我们会重放其中的消息。

我们有以下要求：

• 持久性 - 消息应写入持久存储
• 可靠的网络复制 - 日志技术应该（同步）复制到多个节点，因此我们可以确保在一个节点出现故障时数据不会丢失

到目前为止，我们考虑了以下满足上述要求的技术：

• Chronicle Queue - 仅在企业版中复制
• 阿帕奇卡夫卡

我想请教适合这种情况的其他技术的建议。

• 日记模式

data=journal 模式提供完整的数据和元数据日志。所有新数据首先写入日志，然后写入其最终位置。

如果发生崩溃，可以重播日志，使数据和元数据处于一致状态。这种模式是最慢的，除非需要同时从磁盘读取数据和将数据写入磁盘，它的性能优于所有其他模式。启用此模式将禁用延迟分配和 O_DIRECT 支持。

在这里我有几个问题，请看一下：

1. 配置data=journal，然后用户调用write()，是数据写入journal成功后write()返回，还是进入pagecache后返回用户成功？如果是后者，就说明journal是异步提交的，那么ext4的journal的意义就是保证文件系统本身的一致性，不保证用户数据不会丢失？

2. 如果ext4异步提交日志，什么时候触发日志？

3. 是否有任何其他文件系统允许在 write() 成功返回之前同步日志？

根据我本地实验的结果，推断该期刊应该是异步提交的。我使用了一个单独的 ssd 分区作为 journal_dev。我用fio测试写文件的时候发现journal_dev的io是断断续续的，不是一直都有IO。

1. 在下面的文章中，它说“有序模式只是元数据日记，但在记录元数据之前写入数据。” 这是否意味着在写入元数据之前将数据物理写入磁盘？据我了解，写入磁盘的数据首先放在缓存中，然后刷新到磁盘。或者数据是否实际写入磁盘与日志服务无关？
2. 放置在日志中的元数据是否直接写入磁盘而不首先写入缓存？