Hi out there,
I have a problem using my MO-Drive under kernel 2.4.3. I have several disks
formated with a VFAT filesystem. Under kernel 2.2.19 everything works fine.
Under kernel 2.4.3 I cannot write anything to the disk without hanging the
complete system so that I have to use the reset button. For disks with an
ext2 filesystem it works okay.
Regards
Detlev
--
Detlev Offenbach
[email protected]
> I have a problem using my MO-Drive under kernel 2.4.3. I have several disks
> formated with a VFAT filesystem. Under kernel 2.2.19 everything works fine.
> Under kernel 2.4.3 I cannot write anything to the disk without hanging the
> complete system so that I have to use the reset button. For disks with an
> ext2 filesystem it works okay.
This is a bug in the scsi layer. [email protected], not that any of
the scsi maintainers seem to care about it right now.
Hi Alan,
thanks for the reply.
Am Freitag, 13. April 2001 15:08 schrieb Alan Cox:
> > I have a problem using my MO-Drive under kernel 2.4.3. I have several
> > disks formated with a VFAT filesystem. Under kernel 2.2.19 everything
> > works fine. Under kernel 2.4.3 I cannot write anything to the disk
> > without hanging the complete system so that I have to use the reset
> > button. For disks with an ext2 filesystem it works okay.
>
> This is a bug in the scsi layer. [email protected], not that any
> of the scsi maintainers seem to care about it right now.
Does this mean I can forget about using kernel 2.4.x? :-(( Can you give me a
hint where to look. Maybe I can fix it myself.
Regards
Detlev
--
Detlev Offenbach
[email protected]
On Fri, Apr 13, 2001 at 02:08:41PM +0100, Alan Cox wrote:
> > I have a problem using my MO-Drive under kernel 2.4.3. I have several disks
> > formated with a VFAT filesystem. Under kernel 2.2.19 everything works fine.
> > Under kernel 2.4.3 I cannot write anything to the disk without hanging the
> > complete system so that I have to use the reset button. For disks with an
> > ext2 filesystem it works okay.
>
> This is a bug in the scsi layer. [email protected], not that any of
> the scsi maintainers seem to care about it right now.
Err..., now I'm confused. Last time this issue popped up, it was my
understanding that it's generic_file_{read,write}'s limitation to filesystems
with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
this all moot, or is the SCSI thing just an additional problem?
Regards,
Daniel.
--
GNU/Linux Audio Mechanics - http://www.glame.de
Cutting Edge Office - http://www.c10a02.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
> > This is a bug in the scsi layer. [email protected], not that any
> > of the scsi maintainers seem to care about it right now.
>
> Does this mean I can forget about using kernel 2.4.x? :-(( Can you give me a
> hint where to look. Maybe I can fix it myself.
The FAT layer asks for a 512 byte block, the scsi layer in 2.2 would then
reblock the data to handle this internally. In 2.4 the scsi layer errors this
then all the error handling gets tangled up (and doesnt work) and the machine
oopses.
So you either need to teach lots of file systems about handling blocks that
are smaller than the physical layer, or the block layer to do reblocking in
some cases (at an obvious performance hit).
And someone needs to fix the error handling so it errors rather than exploding
> > This is a bug in the scsi layer. [email protected], not that any of
> > the scsi maintainers seem to care about it right now.
>
> Err..., now I'm confused. Last time this issue popped up, it was my
> understanding that it's generic_file_{read,write}'s limitation to filesystems
> with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
> this all moot, or is the SCSI thing just an additional problem?
generic_file_* doesnt handle metadata issues - its too high up
On Sat, Apr 14, 2001 at 03:29:45PM +0100, Alan Cox wrote:
> > > This is a bug in the scsi layer. [email protected], not that any of
> > > the scsi maintainers seem to care about it right now.
> >
> > Err..., now I'm confused. Last time this issue popped up, it was my
> > understanding that it's generic_file_{read,write}'s limitation to filesystems
> > with logical_blksize >= hw_blksize that makes MOs fail with VFAT. Now, is
> > this all moot, or is the SCSI thing just an additional problem?
>
> generic_file_* doesnt handle metadata issues - its too high up
As much as SCSI is too low down, so I still don't see why this should be a
SCSI issue. Assuming requests are no smaller than hw_blksize looks rather sane
for a low-level driver. It's still enforced in ll_rw_blk(). I'd rather blame
the callers when they bypass the check via submit_bh().
More to the topic, FAT in 2.2 contained lots of special code to deal with
bigblocks. In 2.4, this code got removed in favour of the generic
functions in fs/buffer.c, to the effect that operations that happen to not
deref a NULL pointer now request 2k blocks using 512 byte-calculated block
numbers. I see two options:
a) Put in lots of bigblock special case code in FAT;
b) teach submit_bh() or generic_make_request() to transparently reblock
bhs < hw_blksize and remove most special cases from FAT. Specifically,
it ought to stop pretending in sb->s_blocksize to use 2k blocks when
the fs is really tied to 512 byte blocks.
I tend to favour b), but which one is more likely to be accepted?
Regards,
Daniel.
--
GNU/Linux Audio Mechanics - http://www.glame.de
Cutting Edge Office - http://www.c10a02.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
> a) Put in lots of bigblock special case code in FAT;
> b) teach submit_bh() or generic_make_request() to transparently reblock
> bhs < hw_blksize and remove most special cases from FAT. Specifically,
> it ought to stop pretending in sb->s_blocksize to use 2k blocks when
> the fs is really tied to 512 byte blocks.
>
> I tend to favour b), but which one is more likely to be accepted?
Al Viro suggested c) which was to transparently make it a loopback mount of
the raw device and let a loopback layer do the work.
On Sun, Apr 22 2001, Alan Cox wrote:
> > a) Put in lots of bigblock special case code in FAT;
> > b) teach submit_bh() or generic_make_request() to transparently reblock
> > bhs < hw_blksize and remove most special cases from FAT. Specifically,
> > it ought to stop pretending in sb->s_blocksize to use 2k blocks when
> > the fs is really tied to 512 byte blocks.
> >
> > I tend to favour b), but which one is more likely to be accepted?
>
> Al Viro suggested c) which was to transparently make it a loopback mount of
> the raw device and let a loopback layer do the work.
... which is basically the same thing, in that we need to support writes
< hardware block size to devices. This is never going to be an efficient
mechanism, the read gathering required for a 512b write on a 2048b media
is scary. Think cd-rw 64kB blocksize for write. Ugh.
--
Jens Axboe