Re: POSIX violation by writeback error

[Rogier Wolff <R.E.Wolff@BitWizard.nl>]

On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > On Tue, Sep 4, 2018 at 7:09 PM Jeff Layton <jlayton@redhat.com> wrote:
> > > 
> > > On Tue, 2018-09-04 at 16:58 +0800, Trol wrote:
> > > > That is certainly not possible to be done. But at least, shall we report
> > > > error on read()? Silently returning wrong data may cause further damage,
> > > > such as removing wrong files since it was marked as garbage in the old file.
> > > > 
> > > 
> > > Is the data wrong though? You tried to write and then that failed.
> > > Eventually we want to be able to get at the data that's actually in the
> > > file -- what is that point?
> > 
> > The point is silently data corruption is dangerous. I would prefer getting an
> > error back to receive wrong data.
> > 
> 
> Well, _you_ might like that, but there are whole piles of applications
> that may fall over completely in this situation. Legacy usage matters
> here.

Can I make a suggestion here?

First imagine a spherical cow in a vacuum..... 

What I mean is: In the absence of boundary conditions (the real world)
what would ideally happen?

I'd say: 

* When you've written data to a file, you would want to read that
  written data back. Even in the presence of errors on the backing
  media.

But already this is controversial: I've seen time-and-time again that
people with raid-5 setups continue to work untill the second drive
fails: They ignored the signals the system was giving: "Please replace
a drive".

So when a mail queuer puts mail the mailq files and the mail processor
can get them out of there intact, nobody is going to notice.  (I know
mail queuers should call fsync and report errors when that fails, but
there are bound to be applications where calling fsync is not
appropriate (*))

So maybe when the write fails, the reads on that file should fail?

Then it means the data required to keep in memory is much reduced: you
only have to keep the metadata.

In both cases, semantics change when a reboot happens before the
read. Should we care? If we can't fix it when a reboot has happened,
does it make sense to do something different when a reboot has NOT
happened?

	Roger. 



(*) I have 800Gb of data I need to give to a client. The
truck-of-tapes solution of today is a 1Tb USB-3 drive. Writing that
data onto the drive runs at 30Mb/sec (USB2 speed: USB3 didn't work for
some reason) for 5-10 seconds and then slows down to 200k/sec for
minutes at a time. One of the reasons might be that fuse-ntfs is
calling fsync on the MFT and directory files to keep stuff consistent
just in case things crash. Well... In this case this means that
copying the data took 3 full days instead of 3 hours. Too much calling
fsync is not good either.

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.