* loop device changes the block size and causes misaligned accesses to the real device, which can't be processed
@ 2004-01-07 17:03 Ruben Garcia
2004-01-07 18:12 ` loop device changes the block size and causes misaligned accessesto " Jari Ruusu
2004-01-08 4:04 ` [PATCH] Re: loop device changes the block size and causes misaligned accesses to " Ben Slusky
0 siblings, 2 replies; 6+ messages in thread
From: Ruben Garcia @ 2004-01-07 17:03 UTC (permalink / raw)
To: linux-kernel
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: loop device changes the block size and causes misaligned accessesto the real device, which can't be processed
2004-01-07 17:03 loop device changes the block size and causes misaligned accesses to the real device, which can't be processed Ruben Garcia
@ 2004-01-07 18:12 ` Jari Ruusu
2004-01-12 4:12 ` Bill Davidsen
2004-01-08 4:04 ` [PATCH] Re: loop device changes the block size and causes misaligned accesses to " Ben Slusky
1 sibling, 1 reply; 6+ messages in thread
From: Jari Ruusu @ 2004-01-07 18:12 UTC (permalink / raw)
To: Ruben Garcia; +Cc: linux-kernel
Ruben Garcia wrote:
> 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
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Re: loop device changes the block size and causes misaligned accesses to the real device, which can't be processed
2004-01-07 17:03 loop device changes the block size and causes misaligned accesses to the real device, which can't be processed Ruben Garcia
2004-01-07 18:12 ` loop device changes the block size and causes misaligned accessesto " Jari Ruusu
@ 2004-01-08 4:04 ` Ben Slusky
2004-01-08 10:45 ` Ruben Garcia
1 sibling, 1 reply; 6+ messages in thread
From: Ben Slusky @ 2004-01-08 4:04 UTC (permalink / raw)
To: Ruben Garcia; +Cc: linux-kernel, trivial
On Wed, 07 Jan 2004 18:03:48 +0100, Ruben Garcia wrote:
> 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.
--- linux-2.6.0/drivers/block/loop.c-orig 2004-01-07 22:47:37.755375858 -0500
+++ linux-2.6.0/drivers/block/loop.c 2004-01-07 22:48:04.990990082 -0500
@@ -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,
--
Ben Slusky | The doctors x-rayed my head
sluskyb@paranoiacs.org | and found nothing.
sluskyb@stwing.org | -Dizzy Dean
PGP keyID ADA44B3B
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: loop device changes the block size and causes misaligned accesses to the real device, which can't be processed
2004-01-08 4:04 ` [PATCH] Re: loop device changes the block size and causes misaligned accesses to " Ben Slusky
@ 2004-01-08 10:45 ` Ruben Garcia
2004-01-12 14:12 ` Ruben Garcia
0 siblings, 1 reply; 6+ messages in thread
From: Ruben Garcia @ 2004-01-08 10:45 UTC (permalink / raw)
Cc: linux-kernel
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
Ben Slusky wrote:
> On Wed, 07 Jan 2004 18:03:48 +0100, Ruben Garcia wrote:
>
>>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.
>
> --- linux-2.6.0/drivers/block/loop.c-orig 2004-01-07 22:47:37.755375858 -0500
> +++ linux-2.6.0/drivers/block/loop.c 2004-01-07 22:48:04.990990082 -0500
> @@ -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,
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: loop device changes the block size and causes misaligned accessesto the real device, which can't be processed
2004-01-07 18:12 ` loop device changes the block size and causes misaligned accessesto " Jari Ruusu
@ 2004-01-12 4:12 ` Bill Davidsen
0 siblings, 0 replies; 6+ messages in thread
From: Bill Davidsen @ 2004-01-12 4:12 UTC (permalink / raw)
To: linux-kernel
Jari Ruusu wrote:
> Ruben Garcia wrote:
>
>>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...
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: loop device changes the block size and causes misaligned accesses to the real device, which can't be processed
2004-01-08 10:45 ` Ruben Garcia
@ 2004-01-12 14:12 ` Ruben Garcia
0 siblings, 0 replies; 6+ messages in thread
From: Ruben Garcia @ 2004-01-12 14:12 UTC (permalink / raw)
Cc: linux-kernel
Ruben Garcia wrote:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-12 14:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-07 17:03 loop device changes the block size and causes misaligned accesses to the real device, which can't be processed Ruben Garcia
2004-01-07 18:12 ` loop device changes the block size and causes misaligned accessesto " Jari Ruusu
2004-01-12 4:12 ` Bill Davidsen
2004-01-08 4:04 ` [PATCH] Re: loop device changes the block size and causes misaligned accesses to " Ben Slusky
2004-01-08 10:45 ` Ruben Garcia
2004-01-12 14:12 ` Ruben Garcia
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).