public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Sven Köhler" <skoehler@upb.de>
To: linux-kernel@vger.kernel.org
Subject: [blockdevices/NBD] huge read/write-operations are splitted by the kernel
Date: Mon, 08 Sep 2003 02:02:30 +0200	[thread overview]
Message-ID: <bjgh6a$82o$1@sea.gmane.org> (raw)

Hi,

i discussed a problem of the NBD-protocl with Pavel Machek. The problem 
i saw is that there is no maximum for the length field in the requests 
that the NBD kernel module sends to the NBD server. Well, this length 
field is the length field from the read/write-operation that the kernel 
delegates to the blockdevice-implementation.
I did some tests tests like
   dd if=dev/nbd/0 of=/dev/null bs=10M
and our NBD-server implementation printed out the length field of each 
reqeust. There was a very regular pattern like
   0x1fc00 (127KB)
   0x00400 (1KB)
   0x1fc00
   0x00400
   ...
Well, can anybody explain that to me?
(why so "little" 1KB requests? but that's not important)

Well, i also tested
   dd if=dev/nbd/0 of=/dev/null bs=1
which means that the device will be read in chunks of 1byte.
The result was the same: 127KB, 1KB, 127KB, 1KB...

I guess the caching layer is inbetween, and will devide the huge 10MB 
requests into smaller 127KB ones, as well as joining the small 1byte 
requests by using read-ahead i guess.
Perhaps you could tell me how i can turn off caching. Than i will test 
again without the cache.

The thing i want to know is, if there is any part of the kernel that 
gaarantees that a read/write requests will not be bigger that a certain 
value. If there is no such upper limit, the NBD itself would need to 
split things up which might become a complicated task. This task need to 
be done, because it can become very difficult for the NBD server to 
handle huge values, and one huge requests will block all other pending 
small ones due to limitations of the NBD protocol.

Thx
   Sven



             reply	other threads:[~2003-09-08  0:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-08  0:02 Sven Köhler [this message]
2003-09-08  8:58 ` [blockdevices/NBD] huge read/write-operations are splitted by the kernel Jens Axboe
2003-09-08 12:42   ` Sven Köhler
2003-09-08 14:33     ` Jens Axboe
2003-09-08 13:26   ` Sven Köhler
2003-09-08 14:34     ` 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='bjgh6a$82o$1@sea.gmane.org' \
    --to=skoehler@upb.de \
    --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