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. Rich -- 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
