文件系统如何实现扇区锁定？

Question

虽然这是一个一般性问题，但欢迎针对任何 Windows 或 Linux 或 Mac 支持的文件系统提供具体答案。

文件系统如何防止 2 个或更多进程同时读/写访问本地驱动器的扇区？

我知道显然需要采用某种类型的扇区锁定，但是...

1. 这个操作系统范围的扇区锁的“类型”是什么：

   a) 命名互斥/命名信号量/文件映射？ （在 Windows 上）

   b) 共享内存？ （在 Linux 上）

2. 这个扇区锁保存在哪里：在内存中？在磁盘上？无论哪种情况，无论此锁存储在何处，我都知道...

   a) 锁的存储必须是逻辑上的临时存储，因为如果它的所有者进程崩溃，锁不应永久或无限期地悬空。因此，如果这些锁存在于内存中会有所帮助。

   b) 锁的下落必须由所有进程通过名称或 ID 公开发现，该名称或 ID 找到了扇区号的函数。因此，如果进程 A 需要锁定扇区 S，A 应该知道如何首先访问扇区 S 的锁 L(S)，如果 L(S) 尚不存在，则创建 L(S)，尝试锁定 L(S)，并且要么返回要么阻塞——所有这些都是原子的，因为另一个进程 B 也可能与 A 一起竞争，试图执行相同的步骤序列。

3. 对于大型存储设备，扇区数也会很大。因此，显然不能在内存或磁盘上预先分配每个扇区的锁。

然而，我不知道或不理解的是，Linux 上的 ext* 文件系统、Windows 上的 FAT* 和 NTFS 以及 Mac 上的文件系统如何处理这个问题。

我的问题的实际上下文： 最终，我必须将上述答案应用于我正在使用 Java 7 NIO2 FileSystemProvider 编写的基于 Java 的自定义文件系统，其中 2 个或更多独立 Java 进程可能正在访问连接驱动器的一堆扇区以进行读/写。在 Java 7 中，我所知道的在进程之间实现共享内存的唯一非 JNI 方法是通过 MappedByteBuffer。但问题是，这个字节缓冲区将是“原始”内存——而我需要的是一个操作系统范围的互斥体类型机制，并且每个扇区 S 也可能每个互斥体。看来，我对这个 MappedByteBuffer 的更改除非我也调用MappedByteBuffer.force，否则不会在操作系统范围内以原子方式执行。

非常感谢所有答案和 cmets。

Answer 1

我认为您对现代文件系统的实现方式感到困惑，而旧系统通常不是多用户的；有了这个前言，让我们看一下称为journal 的东西。现在有一些替代方案 - 即

1. Soft updates
2. Log-structured file system
3. Copy-on-write

然而，最常见的可能是日志文件系统。它写入空块并在写入完成时简单地移动指针（同时原子地写入“日志”），这允许在电源故障（或其他写入中断）的情况下“快速”恢复。

至于在系统级别锁定您的“日志”，我可能会像这样使用FileLock -

FileLock lock = null;
FileChannel channel = null;
try {
  // Get a file channel for the file
  File file = new File("journal");
  channel = new RandomAccessFile(file,
      "rw").getChannel();

  // Try acquiring the lock without blocking.
  try {
    lock = channel.tryLock();
    if (lock != null) {
      // GOT THE LOCK.... DO WORK...
      return true; // write success.
    }
  } catch (OverlappingFileLockException e) {
    // File is already locked in this thread or virtual
    // machine
  } finally {
    if (lock != null) {
      lock.release(); // Release the lock
    }
    if (channel != null) {
      channel.close(); // Close the file.
    }
  }
  return false; // Write must be retried?