public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jan Kasprzak <kas@informatics.muni.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: drivers/block/loop.c:max_loop
Date: Mon, 16 Apr 2001 20:44:37 +0200	[thread overview]
Message-ID: <20010416204437.K9539@suse.de> (raw)
In-Reply-To: <20010416173942.G6934@informatics.muni.cz> <20010416183637.G9539@suse.de> <20010416200012.H6934@informatics.muni.cz>
In-Reply-To: <20010416200012.H6934@informatics.muni.cz>; from kas@informatics.muni.cz on Mon, Apr 16, 2001 at 08:00:12PM +0200

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Mon, Apr 16 2001, Jan Kasprzak wrote:
> Jens Axboe wrote:
> : On Mon, Apr 16 2001, Jan Kasprzak wrote:
> : > 	Hello,
> : > 
> : > 	I run a relatively large FTP server, and I've just reached
> : > the max_loop limit of loop devices here (I use loopback mount of ISO 9660
> : > images of Linux distros here). Is there any reason for keeping
> : > the max_loop variable in loop.c set to 8?
> : 
> : Memory requirements -- nothing prevents you from loading it with a
> : bigger max count though...
> : 
> 	I would suggest to make the limit configurable by /proc or
> ioctl() in run-time. Or even better, to make all allocations on
> first /dev/loopN open. Should I try to implement something like that?

Overkill, imo. If you use a module setup, add a max_loop to your
/etc/modules.conf. If not, add the identical max_loop to your lilo.conf
append line.

Ok, just noticed that the module option is missing. Attached patch
should rectify that oversight.

-- 
Jens Axboe


[-- Attachment #2: loop-maxloop-mod-1 --]
[-- Type: text/plain, Size: 762 bytes --]

--- /opt/kernel/linux-2.4.4-pre3/drivers/block/loop.c	Sun Apr 15 16:24:12 2001
+++ drivers/block/loop.c	Mon Apr 16 20:43:39 2001
@@ -476,7 +476,7 @@
 	 */
 	bh = loop_get_buffer(lo, rbh);
 	bh->b_private = rbh;
-	IV = loop_get_iv(lo, bh->b_rsector);
+	IV = loop_get_iv(lo, rbh->b_rsector);
 	if (rw == WRITE) {
 		set_bit(BH_Dirty, &bh->b_state);
 		if (lo_do_transfer(lo, WRITE, bh->b_data, rbh->b_data,
@@ -620,7 +620,6 @@
 		 * If we can't read - sorry. If we only can't write - well,
 		 * it's going to be read-only.
 		 */
-		error = -EINVAL;
 		if (!aops->readpage)
 			goto out_putf;
 
@@ -1034,6 +1033,8 @@
 
 module_init(loop_init);
 module_exit(loop_exit);
+
+MODULE_PARM(max_loop, "i");
 
 #ifndef MODULE
 static int __init max_loop_setup(char *str)

  reply	other threads:[~2001-04-16 18:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-16 15:39 drivers/block/loop.c:max_loop Jan Kasprzak
2001-04-16 16:36 ` drivers/block/loop.c:max_loop Jens Axboe
2001-04-16 18:00   ` drivers/block/loop.c:max_loop Jan Kasprzak
2001-04-16 18:44     ` Jens Axboe [this message]
2001-04-16 18:50       ` drivers/block/loop.c:max_loop Jens Axboe

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=20010416204437.K9539@suse.de \
    --to=axboe@suse.de \
    --cc=kas@informatics.muni.cz \
    --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