Hi,
> > Although, I should say this is a bad idea. A full thin pool will return an
> > ENOSPC error to the filesystem, and, the filesystem should act accordingly.
> >
> > Would you want the filesystem to shut down because it hit an ENOSPC, or report
> > to the user and let him/her to take the appropriate action, like freeing space
> > or increasing the dm-thin pool size?
>
> Does a full thin pool *really* report a ENOSPC? On all my tests, I simply
> see "buffer i/o error on dev" on dmesg output (see below). How can I see if
> a ENOSPC was returned?
Yes, it does, unless you are using an old version of dm-thin module:
commit c3667cc6190469d2c7196c2d4dc75fcb33a0814f
Author: Mike Snitzer <snitzer@xxxxxxxxxx>
Date: Thu Mar 10 11:31:35 2016 -0500
dm thin: consistently return -ENOSPC if pool has run out of data space
It used to return EIO, then we decided it should return ENOSPC instead of EIO.
See my comments in your next e-mail
> > The behavior really depends on several configurations, including how dm-thin
> > will deal with ENOSPC situations, dm-thin can be configured to queue new
> > incoming IOs, fail the IO, etc, but, even in a full disk situation, you can
> > still rewrite data, so this behavior doesn't change much from what would happen
> > if you fill up a regular block device, XFS will try to allocate a new block, the
> > block device returns an ENOSPC and XFS acts accordingly.
>
> I am testing with "errorwhenfull=y" when thin pool fills.
>
Ok, so it should return -ENOSPC
> > What exactly do you mean by failed data update? As long as you don't need to
> > allocate any new block either for data of metadata, you should be able to rewrite
> > data normally if the device is full.
>
> I refer to update for which the metadata write completes successfully (ie:
> they are writen to already-allocated space), but the data writeout does
> *not* (ie: new data require a new allocation, which it fails).
>
Yup, will make XFS complain about metadata errors, once it can't writeback data
queued in AIL.
> Can you link to the bug?
>
https://www.spinics.net/lists/linux-xfs/msg06986.html
> Thanks a lot.
>
> --
> 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
--
Carlos
--
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
