On Tue, Oct 06, 2015 at 12:42:02PM -0700, Mark Fasheh wrote:
> Hmm this isn't working for me, am I doing anything wrong?
You are not, there's a bug in the 'subvol sync' command sorry. I found
it just yesterday.
https://patchwork.kernel.org/patch/7334131/
I'll do a progs release soon with this f
On Tue, Oct 06, 2015 at 10:09:26AM -0700, Mark Fasheh wrote:
> On Tue, Oct 06, 2015 at 10:25:52AM +0200, David Sterba wrote:
> > On Thu, Oct 01, 2015 at 02:30:47PM -0700, Mark Fasheh wrote:
> > > At the moment, userspace has no way of knowing when a snapshot is finally
> > > removed. This has becom
On Tue, Oct 06, 2015 at 10:25:52AM +0200, David Sterba wrote:
> On Thu, Oct 01, 2015 at 02:30:47PM -0700, Mark Fasheh wrote:
> > At the moment, userspace has no way of knowing when a snapshot is finally
> > removed. This has become a problem when writing tests for btrfs,
> >
> > http://article.gma
On Thu, Oct 01, 2015 at 02:30:47PM -0700, Mark Fasheh wrote:
> At the moment, userspace has no way of knowing when a snapshot is finally
> removed. This has become a problem when writing tests for btrfs,
>
> http://article.gmane.org/gmane.comp.file-systems.fstests/1239/
In the meantime the comman
Dropping a subvolume in btrfs is a delayed operation which can persist
across mounts (or crashes) - progress for the subvolume drop is recorded in
a key on the root object.
At the moment, userspace has no way of knowing when a snapshot is finally
removed. This has become a problem when writing tes
