Re: Shutdown filesystem when a thin pool become full

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23/05/2017 01:09, Carlos Maiolino wrote:

If you want that XFS shut down when it hits an error, you can configure it
through sysfs in:

/sys/fs/xfs/<dev>/error/

directory.

You can find detailed info in Documentation/filesystems/xfs.txt (from linux
source).

Very useful documentation, thank you.


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?
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.

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).

How dm-thin and XFS will work together, really depends on how you configure both
of them. XFS has a configuration system that you can use to set how it will
behave in some error situations according to your preferences, it can be set to
retry the writes for a specific amount of time, or simply fail immediately and
shut down the filesystem.

Ok, I need some some testing ;)

Worth to mention though, there is a bug that might be triggered when you
overcommit the space (creates a virtual device larger than the real physical
space), it's not too easy to trigger it though, and the fix is already WIP.

Can you link to the bug?

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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux