All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glauber de Oliveira Costa <glommer@br.ibm.com>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: glommer@br.ibm.com, Anton Altaparmakov <aia21@cam.ac.uk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ext2-devel@lists.sourceforge.net, hirofumi@mail.parknet.co.jp,
	linux-ntfs-dev@lists.sourceforge.net, aia21@cantab.net,
	hch@infradead.org, viro@zeniv.linux.org.uk, akpm@osdl.org
Subject: Re: [PATCH] Use of getblk differs between locations
Date: Mon, 10 Oct 2005 20:33:44 -0300	[thread overview]
Message-ID: <20051010233344.GA13399@br.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0510110112310.27454@artax.karlin.mff.cuni.cz>

On Tue, Oct 11, 2005 at 01:16:59AM +0200, Mikulas Patocka wrote:
> 
> 
> On Mon, 10 Oct 2005, Glauber de Oliveira Costa wrote:
> 
> >
> >>What should a filesystem driver do if it can't suddenly read or write any
> >>blocks on media?
> >
> >Maybe stopping gracefully, warn about what happened, and let the system
> >keep going. You may be right about your main filesystem, but in the case
> >I'm running, for example, my system in an ext3 filesystem, and have a
> >vfat from a usb key. Should my system really hang because I'm not able
> >to read/write to the device?
> 
> getblk won't fail because of I/O error --- it can fail only because of 
> memory management bugs. I think it's right to stop the system in that case 
> --- it's better than silently corrupting data on any device.
> 
> Mikulas
> 
In the code, we see:

if (unlikely(size & (bdev_hardsect_size(bdev)-1) ||
                        (size < 512 || size > PAGE_SIZE))) {

This is where __getblk_slow, and thus, __getblk fails, and it does not
seem to be due to any memory management bug.

-- 
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
glommer@br.ibm.com
=====================================

WARNING: multiple messages have this Message-ID (diff)
From: Glauber de Oliveira Costa <glommer@br.ibm.com>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: glommer@br.ibm.com, Anton Altaparmakov <aia21@cam.ac.uk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ext2-devel@lists.sourceforge.net, hirofumi@mail.parknet.co.jp,
	linux-ntfs-dev@lists.sourceforge.net, aia21@cantab.net,
	hch@infradead.org, viro@zeniv.linux.org.uk, akpm@osdl.org
Subject: Re: [PATCH] Use of getblk differs between locations
Date: Mon, 10 Oct 2005 20:33:44 -0300	[thread overview]
Message-ID: <20051010233344.GA13399@br.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0510110112310.27454@artax.karlin.mff.cuni.cz>

On Tue, Oct 11, 2005 at 01:16:59AM +0200, Mikulas Patocka wrote:
> 
> 
> On Mon, 10 Oct 2005, Glauber de Oliveira Costa wrote:
> 
> >
> >>What should a filesystem driver do if it can't suddenly read or write any
> >>blocks on media?
> >
> >Maybe stopping gracefully, warn about what happened, and let the system
> >keep going. You may be right about your main filesystem, but in the case
> >I'm running, for example, my system in an ext3 filesystem, and have a
> >vfat from a usb key. Should my system really hang because I'm not able
> >to read/write to the device?
> 
> getblk won't fail because of I/O error --- it can fail only because of 
> memory management bugs. I think it's right to stop the system in that case 
> --- it's better than silently corrupting data on any device.
> 
> Mikulas
> 
In the code, we see:

if (unlikely(size & (bdev_hardsect_size(bdev)-1) ||
                        (size < 512 || size > PAGE_SIZE))) {

This is where __getblk_slow, and thus, __getblk fails, and it does not
seem to be due to any memory management bug.

-- 
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
glommer@br.ibm.com
=====================================


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

  reply	other threads:[~2005-10-10 23:23 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-10 20:45 [PATCH] Use of getblk differs between locations Glauber de Oliveira Costa
2005-10-10 21:20 ` Anton Altaparmakov
2005-10-10 21:46   ` Glauber de Oliveira Costa
2005-10-10 21:58     ` Mikulas Patocka
2005-10-10 22:25       ` Anton Altaparmakov
2005-10-10 22:49         ` Mikulas Patocka
2005-10-10 23:12           ` Glauber de Oliveira Costa
2005-10-10 23:16             ` Mikulas Patocka
2005-10-10 23:33               ` Glauber de Oliveira Costa [this message]
2005-10-10 23:33                 ` Glauber de Oliveira Costa
2005-10-10 23:34                 ` Mikulas Patocka
2005-10-10 23:34                   ` Mikulas Patocka
2005-10-10 23:49                   ` Glauber de Oliveira Costa
2005-10-11  7:52           ` Anton Altaparmakov
2005-10-12 19:51             ` Jeff Mahoney
2005-10-12 19:59               ` Mikulas Patocka
2005-10-12 20:07                 ` Jeff Mahoney
2005-10-12 20:12                   ` Mikulas Patocka
2005-10-12 20:14                     ` Anton Altaparmakov
2005-10-12 20:31                       ` Mikulas Patocka
2005-10-12 21:19                         ` Jeff Mahoney
2005-10-12 21:35                         ` Anton Altaparmakov
2005-10-14 11:32                           ` Al Boldi
2005-10-13  0:09                     ` Jamie Lokier
2005-10-13  0:21                       ` Mikulas Patocka
2005-10-13  0:27                         ` Jamie Lokier
2005-10-13 11:17                     ` Pavel Machek
2005-10-14 16:52                       ` Jamie Lokier
2005-10-14 16:52                         ` Jamie Lokier
2005-10-14 18:26                         ` Mikulas Patocka
2005-10-13  0:05                   ` Jamie Lokier
2005-10-12 20:08               ` Anton Altaparmakov
2005-10-10 22:36       ` Glauber de Oliveira Costa
2005-10-10 22:28         ` Anton Altaparmakov
2005-10-10 23:36           ` Andrew Morton
2005-10-11  0:07             ` Glauber de Oliveira Costa
2005-10-11  0:05               ` Al Viro
2005-10-11  0:40                 ` Glauber de Oliveira Costa
2005-10-11 12:35                   ` Jan Hudec
2005-10-11  0:09             ` Mikulas Patocka
2005-10-11  1:07               ` Andrew Morton
2005-10-11  1:20                 ` Mikulas Patocka
2005-10-11  5:02                   ` Andrew Morton
2005-10-11  5:02                     ` Andrew Morton
2005-10-11  8:07                   ` Anton Altaparmakov
2005-10-11  8:01                 ` Anton Altaparmakov
2005-10-13  0:58                   ` Mike Christie

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=20051010233344.GA13399@br.ibm.com \
    --to=glommer@br.ibm.com \
    --cc=aia21@cam.ac.uk \
    --cc=aia21@cantab.net \
    --cc=akpm@osdl.org \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=mikulas@artax.karlin.mff.cuni.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.