Re: [PATCH] Use of getblk differs between locations

[Mikulas Patocka]

> > > > 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.

This is a filesystem bug --- filesystem should set it's blocksize with 
sb_set_blocksize (and refuse to mount if the device doesn't support it) 
before using it in requests.

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/