9

I can't find a simple, straight answer about which filesystem metadata operations are actually persisted to the ext4 & xfs filesystem journals. Note that I am not inquiring about what POSIX declares to be "atomic". I'm more concerned about what subset of atomic filesystem operations are effectively durable by virtue of running with a journal enabled without having to bend over backwards and fsync(2) all the time.

Operations I'm fairly certain count:

  • creat(2)
  • link(2)
  • unlink(2)
  • rename(2)
  • mkdir(2)
  • rmdir(2)

Operations I'm not entirely sure about:

  • symlink(2)

The symlink(2) case is the most troubling, since there does not seem to be any straightforward way to fsync(2) or fdatasync(2) the underlying datablocks that store the content of a symlink. Knowing that the journal takes care of this for me would be a relief.

migrated from stackoverflow.com May 5 '14 at 17:57

This question came from our site for professional and enthusiast programmers.

1

For performance reasons, ext4 by default only writes filesystem metadata through the journal.

I believe XFS also journals all metadata transactions, unless you've tweaked the filesystem.

  • Yeah but what is "metadata" specifically? A directory's blocks: sure. The inodes themselves: yep. Symlinks with a target small enough to fit into the inode itself: probably? Symlinks where the target spills over into auxillary blocks: ?????? – naelyn Apr 29 '14 at 2:23
  • link would help – asdmin Jan 30 '15 at 15:19
0

You are aware that the ext4 journal operates by block number and not operation, correct? "Metadata" would be anything other than that actual data blocks for the given inode, regardless of what operation you used to modify the block in question.

0

I'm more concerned about what subset of atomic filesystem operations are effectively durable by virtue of running with a journal enabled without having to bend over backwards and fsync(2) all the time.

None. If you want to be sure that changes persist after a crash, you must fsync, period. Journaling only guarantees that in the event of a crash, none of the operations you listed will be half done.

  • I know that if I care I must fsync files and directories to know for certain if the blocks have hit spinning rust, but there is no method I have been able to find that lets me fsync the blocks that back a symlink if it spills out of the inode. At that point my only recourse is to rely upon the journal or never ever use symlinks again for anything that matters. – rboyer May 11 '14 at 18:17
  • @naelyn, an fsync() will flush all blocks related to a file, including a non fast symlink. – psusi May 11 '14 at 20:58
  • how do I open an appropriate file descriptor for use in an fsync that would flush a non-fast symlink's blocks? – rboyer May 11 '14 at 21:56
  • @naelyn, oh yea... good point... might need to ask about that one on the linux-fsdevel mailing list... with hard links I believe you open and sync the directory containing it, maybe symlinks work the same? – psusi May 11 '14 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.