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@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
