[Gluster-users] Bad sectors on brick

[Ravishankar N]

On 10/25/2016 05:42 PM, Gandalf Corvotempesta wrote:
> 2016-10-24 16:13 GMT+02:00 Niels de Vos <ndevos at redhat.com>:
>> Yes, correct. But note that different filesystems can handle bad sectors
>> differently, read-only filesystems is the most common default though.
>>
>> In 'man 8 mount' the option "errors=" describes the different values for
>> ext2/3/4. Configuring it to "continue" will most likely cause data
>> corruption or other bad problems and is definitely not advised ;-)
>  From the opennebula forum:
>
> "I think your notion of kernel behaviour during disk failures is not
> correct. First of all, this is heavily filesystem dependent. Moreover,
> when the bad sector is in the file data (as opposed to filesystem
> metadata), read(2)returns something like ENXIO, and the filesystem
> continues operating. When the bad sector is in the filesystem
> metadata, most filesystems remount themselves read-only (AFAIK with
> ext*fs, the exact behaviour can be set via tune2fs(8) as "remount
> r/only", "panic", and "ignore" for the brave :-). When the disk is bad
> to the point of generating unplug/replug sequence (e.g. SATA channel
> reset), the filesystem starts returning ENXIO for all operations, but
> it is still mounted. For systemd-based distributions, systemd
> sometimes detects an unplugged disk (if it is mounted via /etc/fstab
> entry), and umount(2)s it.
>
> The kernel itself does not disable the disk, nor it remounts it r/only
> in response to all types of failure."
>
> so, how gluster handle a ENXIO ?
There is no special handling for specific errors.

i) If a particular syscall fails in the brick process, the errno is
propagated back to the application.

ii) If the posix health-checker thread [1], which runs 
periodically,fails in its
I/O, it kills the brick process, subsequent to which any I/O on that 
brick will
fail with ENOTCONN.

-Ravi

[1] 
https://github.com/gluster/glusterfs/blob/v3.8.5/xlators/storage/posix/src/posix-helpers.c#L1809