Re: Shutdown filesystem when a thin pool become full

[Gionatan Danti <g.danti@assyoma.it>]

Il 20-06-2017 17:28 Brian Foster ha scritto:
> 
> FWIW, I played with something like this a while ago. See the following
> (and its predecessor for a more detailed cover letter):
> 
>   http://oss.sgi.com/pipermail/xfs/2016-April/048166.html
> 
> You lose some allocation efficiency with this approach because XFS
> relies on a worst case allocation reservation in dm-thin, but IIRC that
> only really manifested when the volume was near ENOSPC. If one finds
> that tradeoff acceptable, I think it's otherwise possible to forward
> ENOSPC from the the block device earlier than is done currently.
> 
> Brian

Very informative thread, thanks for linking. From here [1]:

"That just doesn't help us avoid the overprovisioned situation where we
have data in pagecache and nowhere to write it back to (w/o setting the
volume read-only). The only way I'm aware of to handle that is to
account for the space at write time."

I fully understand that: after all, writes sitting in pagecaches are 
not, well, yet written. I can also imagine what profound ramifications 
would have to correctly cover any failed data writeout corner case. What 
would be a great first step, however, is that at the *first* failed data 
writeout due to full thin pool, a ENOSPC (or similar) to be returned to 
the filesystem. Catching this situation, the filesystem can reject any 
further buffered writes until manual intervention.

Well, my main concern is to avoid sunstained writes to a filled pool, 
surely your patch target a whole bigger (and better!) solution.

[1] http://oss.sgi.com/pipermail/xfs/2016-April/048378.html

> 
>> >
>> > I am not really a device-mapper developer and I don't know much about
>> > its code
>> > in depth. But, I know it will issue warnings when there isn't more space
>> > left,
>> > and you can configure a watermark too, to warn the admin when the space
>> > used
>> > reaches that watermark.
>> >
>> > By now, I believe the best solution is to have a reasonable watermark
>> > set on the
>> > thin device, and the Admin take the appropriate action whenever this
>> > watermark
>> > is achieved.
>> 
>> Yeah, lvmthin *will* return appropriate warnings during pool filling.
>> However, this require active monitoring which, albeit a great idea and 
>> "the
>> right thing to do (tm)", it adds complexity and can itself fail. In 
>> recent
>> enought (experimental) versions, lvmthin can be instructed to execute
>> specific actions when data allocation is higher than some threshold, 
>> which
>> somewhat addresses my concerns at the block layer.
>> 
>> Thank you for your patience and sharing, Carlos.
>> 
>> --
>> Danti Gionatan
>> Supporto Tecnico
>> Assyoma S.r.l. - www.assyoma.it
>> email: g.danti@assyoma.it - info@assyoma.it
>> GPG public key ID: FF5F32A8
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8