On Mon, 28 Aug 2017 15:03:47 +0300
Nikolay Borisov wrote:
> when the cleaner thread runs again the snapshot's root item is going to
> be deleted for good and you no longer will see it.
Oh, that's pretty sweet -- it means there's actually a way to reliably wait
for
On Mon, Aug 28, 2017 at 03:03:47PM +0300, Nikolay Borisov wrote:
>
>
> On 28.08.2017 11:07, Christoph Anton Mitterer wrote:
> > Thanks...
> >
> > Still a bit strange that it displays that entry... especially with a
> > generation that seems newer than what I thought was the actually last
> >
On 28.08.2017 11:07, Christoph Anton Mitterer wrote:
> Thanks...
>
> Still a bit strange that it displays that entry... especially with a
> generation that seems newer than what I thought was the actually last
> generation on the fs.
Snapshot destroy is a 2-phase process. The first phase
Thanks...
Still a bit strange that it displays that entry... especially with a
generation that seems newer than what I thought was the actually last
generation on the fs.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On 28.08.2017 06:43, Janos Toth F. wrote:
> ID=5 is the default, "root" or "toplevel" subvolume which can't be
> deleted anyway (at least normally, I am not sure if some debug-magic
> can achieve that).
> I just checked this (out of curiosity) and all my Btrfs filesystems
> report something very
ID=5 is the default, "root" or "toplevel" subvolume which can't be
deleted anyway (at least normally, I am not sure if some debug-magic
can achieve that).
I just checked this (out of curiosity) and all my Btrfs filesystems
report something very similar to yours (I thought DELETED was a made
up
Hey.
Just wondered...
On a number of filesystems I've removed several subvoumes (with -c)...
even called btrfs filesystem sync afterwards... and waited quite a
while (with the fs mounted rw) until no disk activity seems to happen
anymore.
Yet all these fs shows some deleted subvols e.g.:
btrfs