4 ms·

That should be only for creating files, and maybe updating their metadata (not sure about that one). The confusion stems from people thinking that files and di

That should be only for creating files, and maybe updating their metadata (not sure about that one). The confusion stems from people thinking that files and directories are more different than they are. Both are inodes, and both are basically containers for data. File inodes are containers for actual data, while directory inodes are containers for other inodes. All inodes need to be fsynced when you write to them. For files this is obviously when you write data to them. For directories, this is any time you change the inodes they contain, since you’re effectively writing data to them. You only need to sync the direct parent because the containers aren’t transitive; the grandparent directory only stores a reference to the parent directory, not to the files within the parent directory. It’s basically a graph.

xdavidliu 2y ago
> It’s basically a graph. do you mean it's a basically a tree? Because if it were just a graph, you could still have edges from the grandparent to the grandchild in addition to the one from the former to the child
- red_admiral 2y ago
  This ... depends. In normal POSIX land, hard links break the tree structure, for one, so you get a DAG but not a tree. I think some file systems do enforce tree structure, though - hard links are not supported everywhere. It used to be possible ages ago to hard link to directories, which meant that you could have actual cycles and a recursive tree-walking algorithm would never terminated. (As far as I know you can still do this by editing the disk manually, although I think fsck will make a fuss if it detects this.) You can still, with the right syscalls and drivers, do something like hard links on NTFS (I think they're technically called mount points but it's not the same thing as POSIX ones). I'm not sure if you can still make directory cycles, and you're probably a bad person if you do.
  - account42 2y ago
    Logically, ".." is a hard link to the parent directory. This may or may not actually be the case in the filesystem on the disk.
  - monocasa 2y ago
    > , hard links break the tree structure, for one, so you get a DAG but not a tree. More than DAGs, but instead pretty arbitrary graphs since you can express cycles with hard links.
    - Sebb767 2y ago
      > since you can express cycles with hard links You can't if you only allow hard links to files.
- nerdponx 2y ago
  A tree is a specific kind of graph.
RenThraysk 2y ago
In the case of atomic file writing, the rename() doesn't cause a fsync of the parent directory?
- holowoodman 2y ago
  Depends on the file system. In NFS, yes. In others, maybe not.
- altfredd 2y ago
  > rename() doesn't cause a fsync of the parent directory? It does not. At best it will schedule a journal commit asynchronously (I recall that ext4 maintainer complained about adding this "workaround for buggy user code" on lkml). If you want to receive an IO error when renaming fails, make sure to call fsync() yourself.
guappa 2y ago
> while directory inodes are containers for other inodes. Uh? No. You can imagine them as a list of name,inode tuples.
- eyelidlessness 2y ago
  I’m not well versed enough on the subject to know if there’s important nuance here that I’m missing… but that doesn’t sound like a contradiction to me. That’s effectively a map with O(n) access, right? I think I would more generally refer to that as a “collection”, but it certainly contains inodes as you describe it.
  - flotzam 2y ago
    IMO it's better to think of a directory as "containing" only the named references to inodes. Other directories on the same filesystem may contain other named references to the same inodes ("hard links"). The inodes themselves are more like free floating anonymous objects independent of any particular directory, and might not have a named reference at all (O_TMPFILE; or the named reference was deleted but a file descriptor is still open; or orphaned inodes due to filesystem corruption or someone forgetting to fsync the directory after creating a file as masklinn pointed out - e2fsck will link these in /lost+found). This is also why chmod appears to affect other hard links in different directories: Because it actually modifies the inode (file permissions are recorded in that), not the named reference.
    - eyelidlessness 2y ago
      This definitely seems like a more meaningful distinction to me. It’s also closer to the mental model I had coming into the discussion, FWIW. And I think it makes the collection/container terminology distinction sharper too. Depending on context, I think it’s usually reasonable (if imprecise) to describe a bucket of references or pointers to things as a collection of those things. But I don’t think it makes as much sense to call it a container of those things, except in a really abstract sense.

xdavidliu 2y ago

> It’s basically a graph. do you mean it's a basically a tree? Because if it were just a graph, you could still have edges from the grandparent to the grandchild in addition to the one from the former to the child

red_admiral 2y ago
This ... depends. In normal POSIX land, hard links break the tree structure, for one, so you get a DAG but not a tree. I think some file systems do enforce tree structure, though - hard links are not supported everywhere. It used to be possible ages ago to hard link to directories, which meant that you could have actual cycles and a recursive tree-walking algorithm would never terminated. (As far as I know you can still do this by editing the disk manually, although I think fsck will make a fuss if it detects this.) You can still, with the right syscalls and drivers, do something like hard links on NTFS (I think they're technically called mount points but it's not the same thing as POSIX ones). I'm not sure if you can still make directory cycles, and you're probably a bad person if you do.
- account42 2y ago
  Logically, ".." is a hard link to the parent directory. This may or may not actually be the case in the filesystem on the disk.
- monocasa 2y ago
  > , hard links break the tree structure, for one, so you get a DAG but not a tree. More than DAGs, but instead pretty arbitrary graphs since you can express cycles with hard links.
  - Sebb767 2y ago
    > since you can express cycles with hard links You can't if you only allow hard links to files.
nerdponx 2y ago
A tree is a specific kind of graph.

RenThraysk 2y ago

In the case of atomic file writing, the rename() doesn't cause a fsync of the parent directory?

holowoodman 2y ago
Depends on the file system. In NFS, yes. In others, maybe not.
altfredd 2y ago
> rename() doesn't cause a fsync of the parent directory? It does not. At best it will schedule a journal commit asynchronously (I recall that ext4 maintainer complained about adding this "workaround for buggy user code" on lkml). If you want to receive an IO error when renaming fails, make sure to call fsync() yourself.

guappa 2y ago

> while directory inodes are containers for other inodes. Uh? No. You can imagine them as a list of name,inode tuples.

eyelidlessness 2y ago
I’m not well versed enough on the subject to know if there’s important nuance here that I’m missing… but that doesn’t sound like a contradiction to me. That’s effectively a map with O(n) access, right? I think I would more generally refer to that as a “collection”, but it certainly contains inodes as you describe it.
- flotzam 2y ago
  IMO it's better to think of a directory as "containing" only the named references to inodes. Other directories on the same filesystem may contain other named references to the same inodes ("hard links"). The inodes themselves are more like free floating anonymous objects independent of any particular directory, and might not have a named reference at all (O_TMPFILE; or the named reference was deleted but a file descriptor is still open; or orphaned inodes due to filesystem corruption or someone forgetting to fsync the directory after creating a file as masklinn pointed out - e2fsck will link these in /lost+found). This is also why chmod appears to affect other hard links in different directories: Because it actually modifies the inode (file permissions are recorded in that), not the named reference.
  - eyelidlessness 2y ago
    This definitely seems like a more meaningful distinction to me. It’s also closer to the mental model I had coming into the discussion, FWIW. And I think it makes the collection/container terminology distinction sharper too. Depending on context, I think it’s usually reasonable (if imprecise) to describe a bucket of references or pointers to things as a collection of those things. But I don’t think it makes as much sense to call it a container of those things, except in a really abstract sense.