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