Anthony Plack posted on Fri, 08 May 2015 11:44:39 -0500 as excerpted: > Maybe I am over hoping for a COW transaction system to actually have the > ability to fix transaction issues since there is little to no > documentation other than zero the log. I am also wondering why we have > a log in the file system if the fix is to just flush it. I'm not a coder, but for quite some time wondered the same thing, plus why a log at all if it was COW and atomic commits... which you may know, at least at the level I was wondering about it. Then a dev chanced a comment that made it much clearer to me. Hopefully I didn't misunderstand something and the below clarifies things for you as it did for me, or at least for others reading if being a coder, you already had this high level of understanding and were talking about details of the implementation... Btrfs is indeed atomic commit, but in the interest of efficiency, it doesn't commit every little change /all/ the way up the tree. Instead, commit time is every 30 seconds by default, with the log collecting changes between commits, ideally at least, allowing a replay of everything that been partially written since the last commit that hasn't been committed yet -- the changes should be on device in a partially written tree, and the log should allow that partially written tree to be fully committed, thus saving all but perhaps the last actually in-process write at the moment of the crash. With that, the log actually made sense to me, it's just a log of what hasn't been fully committed yet, given that in the interest of efficiency, a full commit is only done every 30 seconds. And then I wasn't quite so concerned either about losing something critical in the log, or the safety of simply blowing it away, since by design, the log only deals with what hasn't been committed yet, and the commits are themselves designed to be atomic and leave the filesystem in a known good state. But beyond that, at my non-coding sysadmin level anyway, I agree with where you seem to be taking this. Currently, there's little to nothing documented or in the output about that log, and it's either keep it all or blow it away. How much nicer it might be to have a bit more detail available, and to be able to actually trace the log and apply or blow away individual partial transactions as necessary, with the trace available so at least coder-level folks could trace exactly why the replay either committed or discarded each between-commits partial transaction, repairing the log instead of whole-hog commit or delete. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
