Re: Snapshots, Dirty Data, and Power Failure

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Thu, Nov 26, 2020 at 09:15:34AM -0500, Ellis H. Wilson III wrote:
> On 11/25/20 10:16 AM, Ellis H. Wilson III wrote:
> > On 11/24/20 11:24 PM, Zygo Blaxell wrote:
> > > On Tue, Nov 24, 2020 at 11:03:15AM -0500, Ellis H. Wilson III wrote:
> > > > 1. Is my presumption just incorrect and there is some other
> > > > time-consuming
> > > > mechanics taking place during a snapshot that would cause these
> > > > longer times
> > > > for it to return successfully?
> > > 
> > > As far as I can tell, the upper limit of snapshot creation time is
> > > bounded
> > > only the size of the filesystem divided by the average write speed, i.e.
> > > it's possible to keep 'btrfs sub snapshot' running for as long as it
> > > takes
> > > to fill the disk.
> > 
> > Ahhh.  That is extremely enlightening, and exactly what we're seeing.  I
> > presumed there was some form of quiescence when a snapshot was taken
> > such that writes that were inbound would block until it was complete,
> > but I couldn't reason about why it was taking SO long to get everything
> > flushed out.  This exactly explains it as we only block out incoming
> > writes to the subvolume being snapshotted -- not other volumes.
> 
> One other potentially related question:
> 
> How does snapshot removal impact snapshot time?  If I issue a non-commit
> snapshot deletion (which AFAIK proceeds in the background), and then a few
> seconds later I take a snapshot of that same subvolume, should I expect to
> have to wait for the snapshot removal to be processed prior to the snapshot
> I just took from completing?

Snapshot deletion is a fast, unthrottled delayed ref generator, so it
will have a significant impact on latency and performance over the entire
filesystem while it runs (and even some time after).  Snapshot delete is
permitted to continue to create new delayed ref updates while transaction
commit is trying to flush them to disk, so the situation is similar to
the writer case--transaction commit can be indefinitely postponed as long
as there is free disk space and deleted subvol data available to remove.

> Best,
> 
> ellis
>