On 03/14/2014 06:40 PM, Rich Freeman wrote:
On Wed, Mar 12, 2014 at 12:34 PM, Rich Freeman
<r-bt...@thefreemanclan.net> wrote:
On Wed, Mar 12, 2014 at 11:24 AM, Josef Bacik <jba...@fb.com> wrote:
On 03/12/2014 08:56 AM, Rich Freeman wrote:
After a number of reboots the system became stable, presumably
whatever race condition btrfs was hitting followed a favorable
path.
I do have a 2GB btrfs-image pre-dating my application of this
patch that was causing the issue last week.
Uhm wow that's pretty epic. I will talk to chris and figure out how
we want to deal with that and send you a patch shortly. Thanks,
A tiny bit more background.
And some more background. I had more reboots over the next two days
at the same time each day, just after my crontab successfully
completed. One of the last thing it does is runs the snapper cleanups
which delete a bunch of snapshots. During a reboot I checked and
there were a bunch of deleted snapshots, which disappeared over the
next 30-60 seconds before the panic, and then they would re-appear on
the next reboot.
I disabled the snapper cron job and this morning had no issues at all.
One day isn't much to establish a trend, but I suspect that this is
the cause. Obviously getting rid of snapshots would be desirable at
some point, but I can wait for a patch. Snapper would be deleting
about 48 snapshots at the same time, since I create them hourly and
the cleanup occurs daily on two different subvolumes on the same
filesystem.
Ok that's helpful, I'm no longer positive I know what's causing this,
I'll try to reproduce once I've nailed down these backref problems and
balance corruption. Thanks,
Josef
--
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
