On Thu, Jul 10, 2014 at 11:32:28AM -0700, Zach Brown wrote:
> On Thu, Jul 10, 2014 at 10:36:14AM -0700, Mark Fasheh wrote:
> > On Thu, Jul 10, 2014 at 10:43:30AM +1000, Dave Chinner wrote:
> > > On Wed, Jul 09, 2014 at 03:41:50PM -0700, Mark Fasheh wrote:
> > > > +
> > > > +# Enable qgroups now that we have our filesystem prepared. This
> > > > +# will kick off a scan which we will have to wait for below.
> > > > +$BTRFS_UTIL_PROG qu en $SCRATCH_MNT
> > > > +sleep 30
> > >
> > > That seems rather arbitrary. The sleeps you are adding add well over
> > > a minute to the runtime, and a quota scan of a filesystem with 200
> > > files should be almost instantenous.
> >
> > Yeah I'll bring that back down to 5 seconds?
>
> How long does it usually take?
>
> What interfaces would be needed for this to work precisely so we don't
> have to play this game ever again?
Well there's also the 'sleep 45' below because we need to be certain that
btrfs_drop_snapshot gets run. This was all a bit of a pain during debugging
to be honest.
So in my experience, an interface to make debugging easier would involve
running every delayed action in the file system to completion, including a
sync of dirty blocks to disk. In theory, this would include any delayed
actions that were kicked off as a result of the actions you are syncing.
You'd do it all from a point in time of course so that we don't spin forever
on a busy filesystem. I do not know whether this is feasible.
Given something like that, you'd just replace the calls to sleep with 'btrfs
fi synctheworldandwait' and know that on return, the actions you just queued
up completed.
--Mark
--
Mark Fasheh
--
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
