From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Pavel Machek <pavel@suse.cz>, Theodore Tso <tytso@mit.edu>,
Chris Friesen <cfriesen@nortel.com>,
kernel list <linux-kernel@vger.kernel.org>,
aviro@redhat.com
Subject: Re: writing file to disk: not as easy as it looks
Date: Wed, 3 Dec 2008 17:52:23 +0000 [thread overview]
Message-ID: <20081203175223.5694ca76@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0812031754040.25439@artax.karlin.mff.cuni.cz>
> error reported for one filesystem may belong to the data written by other
> filesystem. So should some flag "there was an error" be set for all
> partitions and report it to every filesystem when it does cache flush? Or
> record the time of the last error in the driver and let the filesystem
> query it (so that the filesystem can tell if the error happened before or
> after it was mounted).
Good question - not working that high up the stack I don't know the right
answer there.
>
> BTW. how does SCSI report cache flush errors? Does it report them on
> SYNCHRONIZE CACHE command or does it report them on defered senses?
Not sure. I thought the same way.
> Another point is that unless the sector remap table is full, there should
> be no cache flush errors.
You can get them on partial writes to large sector devices, assorted
errors on SSD devices and various 'catastrophic' errors.
> I meant for example loose cable or so --- does it make sense to retry
> indefinitely (until the admin plugs the cable or unmounts the filesystem)
> or return error to the filesystem after few retries?
At the low level we have to return an error so that RAID and the like can
work.
Alan
next prev parent reply other threads:[~2008-12-03 17:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 9:40 Pavel Machek
2008-12-02 14:04 ` Theodore Tso
2008-12-02 15:26 ` Pavel Machek
2008-12-02 16:37 ` Theodore Tso
2008-12-02 17:22 ` Chris Friesen
2008-12-02 20:55 ` Theodore Tso
2008-12-02 22:44 ` Pavel Machek
2008-12-02 22:50 ` Pavel Machek
2008-12-03 5:07 ` Theodore Tso
2008-12-03 8:46 ` Pavel Machek
2008-12-03 15:50 ` Mikulas Patocka
2008-12-03 15:54 ` Alan Cox
2008-12-03 17:37 ` Mikulas Patocka
2008-12-03 17:52 ` Alan Cox [this message]
2008-12-03 18:16 ` Pavel Machek
2008-12-03 18:33 ` Mikulas Patocka
2008-12-03 16:42 ` Theodore Tso
2008-12-03 17:43 ` Mikulas Patocka
2008-12-03 18:26 ` Pavel Machek
2008-12-03 15:34 ` Mikulas Patocka
2008-12-15 10:24 ` [patch] " Pavel Machek
2008-12-15 11:03 ` Pavel Machek
2008-12-15 20:08 ` Folkert van Heusden
2008-12-02 19:10 ` Folkert van Heusden
2008-12-02 23:01 ` Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081203175223.5694ca76@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=aviro@redhat.com \
--cc=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=pavel@suse.cz \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®