Re: Shutdown filesystem when a thin pool become full

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

Il 15-06-2017 17:04 Gionatan Danti ha scritto:
> On 15/06/2017 16:10, Carlos Maiolino wrote:
>> 
>> Disregard this comment, I messed up with some tests, so, basically, 
>> the
>> application is responsible for the user data, and need to use 
>> fsync/fdatasync to
>> ensure the data is properly written, this is not FS responsibility.
>> 
>> cheers
> 
> Hi Carlos,
> I fully agree that it is application responsibility to issue
> appropriate fsync(). However, knowing that this not always happens in
> real-world, I am trying to be as much "fail-safe" as possible.
> 
> From my understanding of your previous message, a full thin pool with
> --errorwhenfull=y should return ENOSPC to the filesystem. Does this
> work on normal cached/buffered/async writes, or with O_DIRECT writes
> only?
> 
> If it is not the case, how can I prevent further writes to a data-full
> thin pool? With ext4, I can use "data=journal,errors=remount-ro" to
> catch any write errors and stop the filesystem (or remount it
> read-only), losing only some seconds worth of data. This *will* works
> even for applications that do not issue fsync(), as the read-only
> filesystem will not let the write() syscall to complete successfully.
> 
> On XFS (which I would *really* use, because it is quite more
> advanced), all writes directed to a full thin-pool will basically end
> on /dev/null and, as write() succeeded, the application/user will
> *not* be alerted on any way. If the thin-pool can communicate its "end
> of free space" to the filesystem, the problem can be avoided.
> 
> If this can not be done, the only remaining possibility is to instruct
> the filesystem to stop itself on data writeout errors. So, we got
> full-circle about my original question: how can I stop XFS when writes
> return I/O errors? Please note that I tried to set any
> /sys/fs/xfs/dm-8/error/metadata/*/max_retries tunable to 0, but I can
> not get the filesystem to suspend itself, even when dmesg reported
> metadata write errors.
> 
> Thank you very much.

Hi all,
any thought on the matter?

Thanks.

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