Skip to contentSkip to conversation

loop device changes the block size and causes misaligned accesses to the real device, which can't be processed

DISCUSSION Ruben Garcia 4 participants 6 messages Jan 7, 2004 – Jan 12, 2004 Block layer

lore
Share & tools
lore
#0 lore raw

The loop device advertises a block size of 1024 even when configured over a cdrom.

When burning a ext2 on a cd, and mounting it directly, I get:

blocksize=2048;

when I losetup /dev/loop0 /dev/cdrom, and then try to mount, I get:

blocksize=1024; and then misaligned transfer; this results in not being able to read the superblock.

The loop device should be changed to export the same blocksize of the underlying device

or

to be able to handle the different blocksize and ask the real disk for the hard sectors; then split them and send them up.

This is needed for crypto, or backup won't mount. (Worked on 2.4.21+Old Cryptoapi)

#1 lore raw

Re: loop device changes the block size and causes misaligned accessesto the real device, which can't be processed

Quoted 2 lines · Ruben Garcia

The loop device advertises a block size of 1024 even when configured over a cdrom.

This bug and many other loop bugs are fixed in loop-AES package.

http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2

Signature · 1 line
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
#3 lore raw
In reply to Ruben Garcia
Quoted 7 lines · Ruben Garcia

The loop device advertises a block size of 1024 even when configured over a cdrom.

When burning a ext2 on a cd, and mounting it directly, I get:

blocksize=2048;

Quoted 7 lines

when I losetup /dev/loop0 /dev/cdrom, and then try to mount, I get:

blocksize=1024; and then misaligned transfer; this results in not being able to read the superblock.

The loop device should be changed to export the same blocksize of the underlying device

Huh, if you look at loop.c it appears to do that already (line 735) but it doesn't. This patch makes it so.

drivers/block/loop.c renamed from drivers/block/loop.c-orig +3 -2
@@ -732,8 +732,6 @@
 	mapping_set_gfp_mask(inode->i_mapping,
 			     lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
 
-	set_blocksize(bdev, lo_blocksize);
-
 	lo->lo_bio = lo->lo_biotail = NULL;
 
 	/*
@@ -749,6 +747,7 @@
 	if (S_ISBLK(inode->i_mode)) {
 		request_queue_t *q = bdev_get_queue(lo_device);
 
+		blk_queue_hardsect_size(lo->lo_queue, q->hardsect_size);
 		blk_queue_max_sectors(lo->lo_queue, q->max_sectors);
 		blk_queue_max_phys_segments(lo->lo_queue,q->max_phys_segments);
 		blk_queue_max_hw_segments(lo->lo_queue, q->max_hw_segments);
@@ -757,6 +756,8 @@
 		blk_queue_merge_bvec(lo->lo_queue, q->merge_bvec_fn);
 	}
 
+	set_blocksize(bdev, lo_blocksize);
+
 	kernel_thread(loop_thread, lo, CLONE_KERNEL);
 	down(&lo->lo_sem);
 

HTH,

Signature · 4 lines
Ben Slusky                      | The doctors x-rayed my head
[email protected]          | and found nothing.
[email protected]              |               -Dizzy Dean
PGP keyID ADA44B3B      
#4 lore raw

Ok, Ben's patch will make the loop device work as any other device, and then ext2 will complain that the hard blocksize is bigger than the blocksize used for ext2 (in my example of 1k for ext2) and fail to mount it.

This is better than getting misaligned transfers et all, and is consistent with using the real device.

On the other hand, it is much more useful being able to actually mount the ext2 fs, and I managed to do that with the loop-aes patch (Thanks Jari Ruusu)

I confirm this bug closed. Thanks to all

Quoted 48 lines · Ben Slusky
Quoted 11 lines · Ruben Garcia

The loop device advertises a block size of 1024 even when configured over a cdrom.

When burning a ext2 on a cd, and mounting it directly, I get:

blocksize=2048;

when I losetup /dev/loop0 /dev/cdrom, and then try to mount, I get:

blocksize=1024; and then misaligned transfer; this results in not being able to read the superblock.

The loop device should be changed to export the same blocksize of the underlying device

Huh, if you look at loop.c it appears to do that already (line 735) but it doesn't. This patch makes it so.

drivers/block/loop.c renamed from drivers/block/loop.c-orig +3 -2
@@ -732,8 +732,6 @@
 	mapping_set_gfp_mask(inode->i_mapping,
 			     lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
 
-	set_blocksize(bdev, lo_blocksize);
-
 	lo->lo_bio = lo->lo_biotail = NULL;
 
 	/*
@@ -749,6 +747,7 @@
 	if (S_ISBLK(inode->i_mode)) {
 		request_queue_t *q = bdev_get_queue(lo_device);
 
+		blk_queue_hardsect_size(lo->lo_queue, q->hardsect_size);
 		blk_queue_max_sectors(lo->lo_queue, q->max_sectors);
 		blk_queue_max_phys_segments(lo->lo_queue,q->max_phys_segments);
 		blk_queue_max_hw_segments(lo->lo_queue, q->max_hw_segments);
@@ -757,6 +756,8 @@
 		blk_queue_merge_bvec(lo->lo_queue, q->merge_bvec_fn);
 	}
 
+	set_blocksize(bdev, lo_blocksize);
+
 	kernel_thread(loop_thread, lo, CLONE_KERNEL);
 	down(&lo->lo_sem);
 

HTH,

#2 lore raw

Re: loop device changes the block size and causes misaligned accessesto the real device, which can't be processed

In reply to Jari Ruusu
Quoted 9 lines · Jari Ruusu
Quoted 2 lines · Ruben Garcia

The loop device advertises a block size of 1024 even when configured over a cdrom.

This bug and many other loop bugs are fixed in loop-AES package.

http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2

This would be really useful in the mainline kernel...

Signature · 3 lines
bill davidsen <[email protected]>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
#5 lore raw
In reply to Ruben Garcia
Quoted 8 lines · Ruben Garcia

Ok, Ben's patch will make the loop device work as any other device, and then ext2 will complain that the hard blocksize is bigger than the blocksize used for ext2 (in my example of 1k for ext2) and fail to mount it.

This is better than getting misaligned transfers et all, and is consistent with using the real device.

On the other hand, it is much more useful being able to actually mount the ext2 fs, and I managed to do that with the loop-aes patch (Thanks Jari Ruusu)

I confirm this bug closed. Thanks to all

I tried Ben's patch and it does work for encrypted CDs (i.e. you can mount them) I'm going to try a non encrypted CD now to see what I find.