On Thu, Aug 14, 2014 at 12:52:35PM -0400, Austin S Hemmelgarn wrote:
> I don't think it is likely that the Samsung SSD is to blame, in my
> experience Samsung's SSD's are better than almost every other brand
> except Intel, and I know that they honor write-barriers correctly.
> The likely issue is that the system hung during the process of a commit,
> which is one of the few things that I know of that consistently corrupts
> the filesystem. There isn't really anything I know of to prevent it,
> except for making your system as stable as possible.
> Interestingly, this type of thing is the only issue I've ever had with
> BTRFS that wasn't traceable to hardware problems.
That was my understanding too, thanks for confirming.
Until this bug gets fixed, I'm perplexed as to why btrfs-zero-log isn't
fixing this.
Can't I unroll the last commits until I get to a stable one?
As luck would have it (again), I'm boarding a plane to Chicago tomorrow to
go speak at linuxcon about btrfs.
I would very much like not to have to spend 12H to restore my SSD from
backup :)
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
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
