On Fri, May 8, 2015 at 5:37 PM, Anthony Plack <tmy@xxxxxxxxx> wrote: > >> On May 8, 2015, at 3:58 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote: >> >> 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. >> > > Duncan, > Thank you for joining me in my monolog here. > > 30 seconds on a server can be allot of data, and is to small of a time span for adequate backups to occur. What you say makes sense, however, without this fixed going forward, BTRFS can never become a serious data storage file system. > Standard disclaimer: not a dev, just a user. I believe the email Duncan referred to was http://www.spinics.net/lists/linux-btrfs/msg43407.html and my understanding was slightly different than his summary. If I understood correctly, by the time an fsync returns success, the BTRFS log will contain all the data needed to comply with the fsync guarantee ("This data has been safely written to media"). If the system goes down before the next full transaction commit (default 30 seconds), then on next rw mount, BTRFS will replay log. The resulting filesystem state is the state of last transaction + fsynced data. In the event of log corruption, BTRFS may experience failures replaying the log. In this case, you can zero the log: then the filesystem state becomes the last transaction, without the last 30 seconds. Normal operation should not result in a corrupt log, since the log is it's own COW tree and is coherently on media before fsync returns. -- 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
