> 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. While there are major distros who have switched to this as their default filesystem, and acknowledging that btrfs has no control over who chooses to do this, there should be more than just a warning about it being unstable, but wholly unreliable. I do get the point that you are relaying what you understood, and it does help me a bit. Since I have a backup (and always I would like another of the data), I thought I would try to help solve an ongoing problem of the tranid issues. I realize I am just stumbling around in the dark, so maybe this comes for nothing in the end. Maybe we need a warning at the top of the BTRFS page that it is highly likely, if BTRFS crashes and the transactions get corrupt, that you WILL loose at a minimum the last 30 seconds of your data and maybe more.-- 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
