From: Ruben Garcia <ruben@ugr.es>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Re: loop device changes the block size and causes misaligned accesses to the real device, which can't be processed
Date: Thu, 08 Jan 2004 11:45:41 +0100 [thread overview]
Message-ID: <3FFD34D5.1080605@ugr.es> (raw)
In-Reply-To: <20040108040414.GA5017@fukurou.paranoiacs.org>
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,
>
next prev parent reply other threads:[~2004-01-08 10:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2004-01-12 14:12 ` Ruben Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FFD34D5.1080605@ugr.es \
--to=ruben@ugr.es \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).