Re: Snapshots, Dirty Data, and Power Failure

["Ellis H. Wilson III" <ellisw@panasas.com>]

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?

Best,

ellis