Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1673940

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

From Theodore Ts'o <tytso@mit.edu>
Newsgroups linux.kernel
Subject Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry
Date 2017-06-24 01:30 +0200
Message-ID <tVGbv-6S-5@gated-at.bofh.it> (permalink)
References (1 earlier) <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> <tVFp8-83f-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jun 23, 2017 at 03:33:46PM -0700, Khazhismel Kumykov wrote:
> 
> 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.

Whether or not it is OK probably depends on how big the directory is.
If we need to suffer through N long error retries, whether it is
caused by long SCSI error retries, or long iSCSI error retries, sooner
or later it's going to be problematic if the process which is taking
forever to search through the whole directory has a some kind health
monitoring service or other watchdog timer.

Still, I agree that there will be some cases where instead of "Fast
fail", having the file server try as hard as possible fetch the file
from the failing disk is worthwhile.  I tend to be focused on the
cluster file system case where if it's going to several hundred
milliseconds to fetch the file, you're better off getting it from the
one other replicated copies from another server, or start the
reed-solomon reconstruction from.  However, if you have an
architecture where the only copy of the file is on the particular file
server (perhaps because you are depending on RAID instead of n=3
replication or reed-solomon erasure codes), having the file server try
as hard as possible to find the file is a good thing.

I wonder if the right answer is to have "fastfail" and "nofastfail"
mount option.

					- Ted

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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