mirror of
https://github.com/Zygo/bees.git
synced 2025-05-17 21:35:45 +02:00
bees: work around btrfs fsync bug
btrfs provides a flush on rename when the rename target exists, so the fsync is not necessary. In the initialization case (when the rename target does not exist and the implicit flush does not occur), the file may be empty or a hole after a crash. Bees treats this case the same as if the file did not exist. Since this condition occurs for only the first 15 minutes of the lifetime of a bees installation, it's not worth bothering to fix. If we attempt to fsync the file ourselves, on a crash with log replay, btrfs will end up with a directory entry pointing to a non-existent inode. This directory entry cannot be deleted or renamed except by deleting the entire subvol. On large filesystems this bug is triggered by nearly every crash (verified on kernels up to 4.5.7). Remove the fsync to avoid the btrfs bug, and accept the failure mode that occurs in the first 15 minutes after a bees install. Signed-off-by: Zygo Blaxell <bees@furryterror.org>
This commit is contained in:
parent
c1e31004b6
commit
6e7137f282
@ -394,8 +394,13 @@ BeesStringFile::write(string contents)
|
||||
Fd ofd = openat_or_die(m_dir_fd, tmpname, FLAGS_CREATE_FILE, S_IRUSR | S_IWUSR);
|
||||
BEESNOTE("writing " << tmpname << " in " << name_fd(m_dir_fd));
|
||||
write_or_die(ofd, contents);
|
||||
#if 0
|
||||
// This triggers too many btrfs bugs. I wish I was kidding.
|
||||
// Forget snapshots, balance, compression, and dedup:
|
||||
// the system call you have to fear on btrfs is fsync().
|
||||
BEESNOTE("fsyncing " << tmpname << " in " << name_fd(m_dir_fd));
|
||||
DIE_IF_NON_ZERO(fsync(ofd));
|
||||
#endif
|
||||
}
|
||||
BEESNOTE("renaming " << tmpname << " to " << m_name << " in FD " << name_fd(m_dir_fd));
|
||||
BEESTRACE("renaming " << tmpname << " to " << m_name << " in FD " << name_fd(m_dir_fd));
|
||||
|
Loading…
x
Reference in New Issue
Block a user