search

maharmstone / btrfs

WinBtrfs - an open-source btrfs driver for Windows
GNU Lesser General Public License v3.0
5.8k stars 222 forks source link

Status of transaction log support #637

Open kode54 opened 6 months ago

kode54 commented 6 months ago

What is the current status of transaction log support? Is there any journaling of disk activity present in the current version (1.9)? The only thing I can find is that there is a transaction log field indicating an unclean log on mount, and a "fix" was to clear the log on mount. It doesn't look like anything is doing any log replay, so I guess that was the best course of action, if you're then going to touch the volume, rather than leave a stale log to be replayed by Linux later.

Is there any work on implementing real transaction log support though?

maharmstone commented 6 months ago

The only thing I can find is that there is a transaction log field indicating an unclean log on mount, and a "fix" was to clear the log on mount. It doesn't look like anything is doing any log replay

That's right - the driver clears any transaction log that Linux might have created, but doesn't do anything else with it.

As far as I can make out, the only practical effect of this is that if you have an O_SYNC file open, do an unclean shutdown and reboot into Windows, the file might be up to 30 seconds out of date. I've not looked at the trans log so far as it seems a pretty niche use-case.

kode54 commented 6 months ago

Gotcha, so it's not as significant as I thought it was. How does it compare to how journaling works on ext3/4?

lesderid commented 6 months ago

Gotcha, so it's not as significant as I thought it was. How does it compare to how journaling works on ext3/4?

Copy-on-write filesystems like btrfs inherently handle unclean shutdowns better than classic filesystems like ext4. Excerpt from https://lwn.net/Articles/576276/:

When data is overwritten in an ext4 filesystem, the new data is written on top of the existing data on the storage device, destroying the old copy. Btrfs, instead, will move overwritten blocks elsewhere in the filesystem and write the new data there, leaving the older copy of the data in place.

The COW mode of operation brings some significant advantages. Since old data is not overwritten, recovery from crashes and power failures should be more straightforward; if a transaction has not completed, the previous state of the data (and metadata) will be where it always was. So, among other things, a COW filesystem does not need to implement a separate journal to provide crash resistance.