From: Andrea Arcangeli <andrea@suse.de>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: linux-kernel@vger.kernel.org,
"Stephen C. Tweedie" <sct@redhat.com>,
Linus Torvalds <torvalds@transmeta.com>,
Alexander Viro <viro@math.psu.edu>, Jens Axboe <axboe@suse.de>
Subject: Re: blkdev in pagecache
Date: Wed, 9 May 2001 15:16:12 +0200 [thread overview]
Message-ID: <20010509151612.D2506@athlon.random> (raw)
In-Reply-To: <20010509043456.A2506@athlon.random> <3AF90A3D.7DD7A605@evision-ventures.com>
In-Reply-To: <3AF90A3D.7DD7A605@evision-ventures.com>; from dalecki@evision-ventures.com on Wed, May 09, 2001 at 11:13:33AM +0200
On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
> > (buffered and direct) to work with a 4096 bytes granularity instead of
>
> You mean PAGE_SIZE :-).
In my first patch it is really 4096 bytes, but yes I agree we should
change that to PAGE_CACHE_SIZE. The _only_ reason it's 4096 fixed bytes is that
I wasn't sure all the device drivers out there can digest a bh->b_size of
8k/32k/64k (for the non x86 archs) and I checked the minimal PAGE_SIZE
supported by linux is 4k. If Jens says I can sumbit 64k b_size without
any problem for all the relevant blkdevices then I will change that in a
jiffy ;). Anyways changing that is truly easy, just define
BUFFERED_BLOCKSIZE to PAGE_CACHE_SIZE instad of 4096 (plus the .._BITS as
well) and it should do the trick automatically. So for now I only cared
to make it easy to change that.
> Exactly, please see my former explanation... BTW.> If you are gogin into
> the range of PAGE_SIZE, it may be very well possible to remove the
> whole page assoociated mechanisms of a buffer_head?
I wouldn't be that trivial to drop it, not much different than dropping
it when a fs has a 4k blocksize. I think the dynamic allocation of the
bh is not that a bad thing, or at least it's an orthogonal problem to
moving the blkdev in pagecache ;).
> Basically this is something which should come down to the strategy
> routine
> of the corresponding device and be fixed there... And then we have this
so you mean the device driver should make sure blk_size is PAGE_CACHE_SIZE
aligned and to take care of writing zero in the pagecache beyond the end
of the device? That would be fine from my part but I'm not yet sure
that's the cleanest manner to handle that.
> Some notes about the code:
>
> kdev_t dev = inode->i_rdev;
> - struct buffer_head * bh, *bufferlist[NBUF];
> - register char * p;
> + int err;
>
> - if (is_read_only(dev))
> - return -EPERM;
> + err = -EIO;
> + if (iblock >= (blk_size[MAJOR(dev)][MINOR(dev)] >>
> (BUFFERED_BLOCKSIZE_BITS - BLOCK_SIZE_BITS)))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> blk_size[MAJOR(dev)] can very well be equal NULL! In this case one is
> supposed to assume blk_size[MAJOR(dev)][MINOR(dev)] to be INT_MAX.
> Are you shure it's guaranteed here to be already preset?
>
> Same question goes for calc_end_index and calc_rsize.
that's a bug indeed (a minor one at least because all the relevant
blkdevices initialize such array and if it's not initialized you notice
before you can make any damage ;), thanks for pointing it out!
Andrea
next prev parent reply other threads:[~2001-05-09 13:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-09 2:34 blkdev in pagecache Andrea Arcangeli
2001-05-09 9:13 ` Martin Dalecki
2001-05-09 12:48 ` Jeff Garzik
2001-05-09 15:03 ` Reto Baettig
2001-05-09 15:04 ` Andrea Arcangeli
2001-05-09 13:16 ` Andrea Arcangeli [this message]
2001-05-09 14:14 ` Jens Axboe
2001-05-09 14:20 ` Andrea Arcangeli
2001-05-09 14:22 ` Jens Axboe
2001-05-09 14:43 ` Martin Dalecki
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=20010509151612.D2506@athlon.random \
--to=andrea@suse.de \
--cc=axboe@suse.de \
--cc=dalecki@evision-ventures.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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