ARTS 0823: 删除链表节点、写进内存不算安全只有 fsync 才扛断电与 Anthropic 扫描再毁掉纸本如何锁住知识

leikooo

2026-08-23 18:11

阅读130

leikooo

2026-08-23 18:11

阅读 130

每周完成一个 ARTS：至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS）

Algorithm

中等题目：https://leetcode.cn/problems/delete-node-in-a-linked-list/?envType=study-plan-v2&envId=selected-coding-interview

一些细节：

1）咱们不知道 head 也不需要知道

2）如果 cur 的值等于需要删除的 node 的值，那么怎么操作呢？

1、咱们不需要返回 head 这个方法是 void

2、如果咱们的需要替换格子 B 那么现在需要把 B 的 next 设置成 D

▼
text
复制代码
格子A     格子B     格子C     格子D
 [4]  →   [5]  →   [1]  →   [9]
           ↑
          node（只能动 B）

3、咱们现在需要最终效果是：A → C → D

那么如果是只能修改 B 和 C，那么咱们直接把 C 的内容设置到 B 即可

▼
java
复制代码
/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode(int x) { val = x; }
 * }
 */
class Solution {
    public void deleteNode(ListNode node) {
        ListNode cur = node;
        while (cur != null) {
            if (cur.val == node.val) {
                cur.val = cur.next.val;
                cur.next = cur.next.next;
                return;
            }
            cur = cur.next;
        }
    }
}

Review

文章： https://oldblog.antirez.com/post/redis-persistence-demystified.html

核心就一句话：写进内存不算安全，write() 只扛进程挂，fsync() 才扛断电；Redis 默认 AOF everysec，最坏丢 2 秒，和 Postgres / MySQL 调完参数之后其实差不多。

大概分为 5 步：

客户端向数据库发送写入命令（数据位于客户端内存中）
数据库接收到写入请求（数据位于服务器内存中）
数据库调用将数据写入磁盘的系统调用（数据位于内核的缓冲区中）
操作系统将写入缓冲区传输到磁盘控制器（数据位于磁盘缓存中）
磁盘控制器实际将数据写入物理介质（磁盘、Nand 芯片、...）

步骤二是设计会非常复杂，有时候会使用其他的线程进行操作

步骤三是 kernel 实现的，一般会有很多层。在 Linux 系统中，一般是文件系统的 page cache，也是使用缓存等到何时的时机再进行提交到磁盘。有些数据库会自己实现这个层，就使用文件系统的 page cache。也有 API 可以跳过 page cache 直接写入数据，比如 O_DIRECT 和 O_SYNC

步骤五，只有执行到步骤五才能说数据是完全安全的，正常情况下执行完步骤三，一般就没有什么问题了。

POSIX API

步骤三：我们可以使用 POSIX API 进行控制，但是我们能控制的有限。比如我们进行系统调用把内容写到文件里面，但是内核写缓冲区的大小是有限的，如果磁盘无法应对应用程序的写入带宽，内核写缓冲区将达到其最大容量，内核就会阻塞我们的写入。这个时候如果有更多的数据来了之后，那么系统就会拒绝这个写入请求。

步骤四：一般来说写入不会太频繁，因为大块的内容写入速度更快。对于 Linux 系统来说默认 30 秒 ，也就是说如果在 30 秒内出现问题，数据还是可能会丢失的。

当然也有办法控制，可以使用 POSIX API 控制立刻写入数据，但是这个 fsync 操作非常消耗资源。

步骤五：严格来说，从这个角度来看，我们无法通过 POSIX API 对其进行控制。也许某些内核实现会尝试告诉驱动器，实际将数据提交到物理介质上，或者控制器反而会为了速度而重新排序写入操作，并不会尽快将数据真正写入磁盘，而是再等待几毫秒。这完全超出了我们的控制范围。

Tips

1）现在 Cursor 支持可以不导入其他 agent 工具的 skills，要不然在 claude 里面的内容全部都跑到 Cursor 里面了。我个人是更习惯分开的，分开便于管理并且不会让 Cursor 的上下文无端增加很多上下文占用。

2）跨会话 skills 推荐：/handoff ，Github 开源地址内容很简单，如下：

▼
text
复制代码
---
name: handoff
description: Write or update a handoff document so the next agent with fresh context can continue this work.
---

Write or update a handoff document so the next agent with fresh context can continue this work.

Steps:
1. Check if HANDOFF.md already exists in the project
2. If it exists, read it first to understand prior context before updating
3. Create or update the document with:
   - **Goal**: What we're trying to accomplish
   - **Current Progress**: What's been done so far
   - **What Worked**: Approaches that succeeded
   - **What Didn't Work**: Approaches that failed (so they're not repeated)
   - **Next Steps**: Clear action items for continuing

Save as HANDOFF.md in the project root and tell the user the file path so they can start a fresh conversation with just that path.

文章：https://annas-archive.gl/blog/physical-destruction.html

核心就一句话：AI 公司在大批买二手书，拆脊扫描后再毁掉纸本，把 2022 年前「没被机器污染」的文字锁进私有服务器；Anna’s Archive 呼吁全球志愿者抢先扫书上传。

Anthropic 的 Project Panama 在 15 亿美元版权和解里被曝光：花几千万买几百万本纸书，训练 Claude，再全部销毁。法官认定合法买书、扫完毁原件算合理使用，破坏性扫描因此比无损扫描更便宜、更能挡住对手、法律风险也更小。纸书没了，数字副本只留公司内部，知识就被永久垄断。作者说这是跟时间赛跑：每人扫一本，一千万志愿者就是一千万份遗产。