[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Loop devices under NTFS
On Tue, 27 Aug 2002, Adam J. Richter wrote:

> On Tue, 27 Aug 2002 at 13:26:44 -0400, Jan Harkes wrote:
> >Not all filesystems use generic_read/generic_write. If they did we
> >wouldn't need those calls in the fops structure.
> My loop.c patch supports files that do not provide
> aops->{prepare,commit}_write (derived from changes by Jari Ruusu
> and Andrew Morton).
> Christoph was arguing that even if the file provides
> aops->{prepare,commit}_write, that there could be a problem using it.
> I am looking for a clear example of that. I don't see the problem
> with using this facility if you first check that it is provided.

smbfs has aops but when used with the current loop.c it corrupts the file
it is using. I can't say that the error is in loop.c but it is the only
way I can trigger the corruption and the smbfs aops (locking) aren't all
that different from the nfs ones.

Here is an example:

# dd if=/dev/zero of=/opt/src/smbfs/share/iozone.tmp bs=1024 count=200000
(/opt/src/smbfs/share is exported by a localhost samba as tmp)
# mount -t -o guest //localhost/tmp /mnt/smb
# losetup /dev/loop0 /mnt/smb/iozone.tmp
# mke2fs /dev/loop0
# mount /dev/loop0 /mnt/tmp
# cp -a ~puw/src/linux/linux-2.4.18/* /mnt/tmp
<something>: Input/Output error
# dmesg
EXT2-fs error (device loop(7,0)): read_block_bitmap: Cannot read block
bitmap - block_group = 0, block_bitmap = 3
EXT2-fs error (device loop(7,0)): read_block_bitmap: Cannot read block
bitmap - block_group = 21, block_bitmap = 172033

I can't say that I understand the problem, and maybe it can be explained
by a need for revalidate as Christoph said earlier in this thread. But
there should be no size changes and any revalidate shouldn't change

When I asked what a filesystem must do to support loop on linux-fsdevel
(May) AM suggested changing loop to use file->read/write (yes, he cleverly
avoided answering my question :).

I made an ugly patch and it fixed the corruption (but broke encryption) to
see if anyone cared about loop. Jari does so he took the idea and included
it with the other things he wants from loop.

Maybe this problem is caused by loop.c not using the aops correctly and
maybe it is an example of what layering violation can do. I wish I
understood this well enough to make it a clear example.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.054 / U:7.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site