Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

From	Khazhismel Kumykov <khazhy@google.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry
Date	2017-06-24 00:40 +0200
Message-ID	<tVFp8-83f-23@gated-at.bofh.it> (permalink)
References	<tVjHX-2OG-1@gated-at.bofh.it> <tVoHD-5Z8-13@gated-at.bofh.it> <tVqJr-7bI-1@gated-at.bofh.it> <tVvSO-24F-17@gated-at.bofh.it> <tVEt3-7qG-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Fri, Jun 23, 2017 at 2:36 PM, Andreas Dilger <adilger@dilger.ca> wrote:
> On Jun 23, 2017, at 6:26 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>
>> The problem is that if we continue, successive reads may all take
>> seconds or minutes to fail, thus tieing up the process for a long
>> time.
>
> Sorry, I don't understand where the seconds or minutes of delay come from?
> Is that because of long SCSI retries in the block layer, or in the disk
> itself, or something caused specifically because of this code?

For a networked block device we may be retrying for a while before
giving up, although this also applies to the initial failed read.

>
>> By returning EIO right away, we can "fast fail".
>
> But it seems like you don't necessarily need to fail at all?  Something like the
> following would return an error if the entry is not found, but still search the
> rest of the leaf blocks (if any) before giving up:
>

Giving up early or checking future blocks both work, critical thing
here is not returning NULL after seeing a read error.
Previously to this the behavior was to continue to check future blocks
after a read error, and it seemed OK.

Khazhy

Thread

[PATCH] ext4: Return EIO on read error in ext4_find_entry Khazhismel Kumykov <khazhy@google.com> - 2017-06-23 01:30 +0200
  Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Theodore Ts'o <tytso@mit.edu> - 2017-06-23 06:50 +0200
    Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Andreas Dilger <adilger@dilger.ca> - 2017-06-23 09:00 +0200
      Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Theodore Ts'o <tytso@mit.edu> - 2017-06-23 14:30 +0200
        Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Andreas Dilger <adilger@dilger.ca> - 2017-06-23 23:40 +0200
          Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Khazhismel Kumykov <khazhy@google.com> - 2017-06-24 00:40 +0200
            Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Theodore Ts'o <tytso@mit.edu> - 2017-06-24 01:30 +0200
              Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Andreas Dilger <adilger@dilger.ca> - 2017-06-24 01:40 +0200
                Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Theodore Ts'o <tytso@mit.edu> - 2017-06-24 02:30 +0200
                Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Tahsin Erdogan <tahsin@google.com> - 2017-06-26 21:30 +0200
                Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Andreas Dilger <adilger@dilger.ca> - 2017-06-26 22:50 +0200
        Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry Pavel Machek <pavel@ucw.cz> - 2017-06-28 00:00 +0200

csiph-web