On Tue, Jun 20, 2017 at 05:03:42PM +0200, Gionatan Danti wrote: > Il 20-06-2017 13:05 Carlos Maiolino ha scritto: > > ... > > Surely this can be improved, but at the end, the application will always > > need to > > check for its own data. > > I think the key improvement would be to let the filesystem know about the > full thin pool - ie: returing ENOSPC at some convenient time (a wild guess: > can we return ENOSPC during delayed block allocation?) > 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 > > > > 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@xxxxxxxxxx - info@xxxxxxxxxx > GPG public key ID: FF5F32A8 > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
