(U|Z)FS consistency and delayed allocation

[Maledictus]

Hi everyone,

I found this interesting to read:
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

And naturally I asked myself what would my favorite FreeBSD act like. Has anyone knowledge about this she or he wants to share? Or any hints where to search for answers to this.

Are fdatawrite() and fdatasync() linux specific?

Thanks

[Maledictus]

The story goes on:
http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/

http://www.advogato.org/person/mjg59/diary.html?start=195

[Djn]

If I'm understanding things right, UFS with softupdates explicitly avoids this issue: Metadate updates (such as a rename) are only done after the associated blocks are written. This apparently uses some form of dependency tree for the operations - I haven't read the paper (http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf) on it yet.

The ext4 issue is in short that metadata is written quickly while the related data writes can be put off for a long time (half a minute and the like). In the case of "write a new file, then rename it over an old file", that means there's a long window where the data on disk refer to a new file that hasn't had its data commited yet.

In order to make this less unpleasant, the current state of ext4 has a hack written in for this case: On a rename, dump the new file to disk immediately. (This is suboptimal, since a chain of updates results in a chain of forced syncs - but better than losing data.)

[Maledictus]

Sounds reasonable. I wasn't aware that softupdates order metadata with data, but if this is so then it shouldn't be a problem.

If I understood the ZFS copy-on-write model right there shouldn't be a problem too.

[Djn]

Don't trust me on it, I pulled it from some random page I saw discussing this. It might be mentioned in the softupdates paper, though - I still haven't gotten around to reading that.