All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.