On Thu, Oct 25, 2012 at 02:03:49PM -0600, cwillu wrote:
> > 3) Want me to try btrfsck although it may make it impossible for me to
> > reproduce the bug and test a fix, as well as potentially break the
> > filesystem
> > more (last time I tried btrfsck, it outputted thousands of lines and never
> > converged
> > to a state it was happy with)
>
> This looks like something btrfs-zero-log would work around (although
> -o recovery should do mostly the same things). That would destroy the
> evidence though, and may just make things (slightly) worse, so I'd
> wait to see if anyone suggests something better before trying it. If
> you're ultimately ending up restoring from backup though, it may save
> you that effort at least.
Thanks for pointing out btrfs-zero-log, I hadn't re-read the wiki page since
this got added.
But I'll hold off at least until tomorrow morning (GMT-7).
If someone would like me to hold off a bit longer, please let me know and
I'll wait for whatever patch you'd like me to try.
As for backups, yes, I have some :) and I also have hourly, daily, weekly
btrfs subvolume snapshots, but I can't use those currently since I can't
mount the base filesystem.
If my latest snapshot is corrupted, once I know which subvolume has the
problem (I can't quite tell since the crash doesn't say which subvolume is
causing it), I can revert to the last hourly snapshot.
Thanks for your reply.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
