Re: fsync error reporting

[tlaronde%polynum.com@localhost]

On Fri, Feb 19, 2021 at 01:43:07AM +0000, David Holland wrote:
> [...]
> 
> (9) We need a model for what happens to the unwritten data. Throwing
> it away is clearly wrong (some may recall a furor a couple years ago
> when it was discovered that Linux did this) but retrying and likely
> failing on every subsequent fsync attempt isn't that useful either.
> My suggestion is to allow retrying up to some arbitrary fixed number
> of times and then mark the buffer broken, and provide some out-of-band
> way to either discard everything (umount -f?) or start retrying again,
> e.g. after manually reinserting accidentally ejected media.
> 

FWIW, perhaps the concept of a dedicated separate recovery data storage (not
specifying it as a physical local disk; could be a remote direct or indirect
storage, energy backed-up memory etc.) could be envisioned for high reliability:
writing unwritten blocks with informations allowing to know what,
where and when and to fix or replay later.

From a superficial point of view, the problems seem all very complicated on the
kernel level. It would be far simpler to have a kernel only allowing
exclusive write to one process, and letting multiplexing be handled by
a file server in user space, this file server being, actually, the only
one to write and read and being the proxy for other processes,
delivering failure messages to whom interested and allowing partial file
locks too.

This is probably not worth more than 2 cts [and don't expect any code in
any reasonable future ;-)].
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C