On Fri, Jan 22, 2010 at 02:28:07PM +0700, Robert Elz wrote:
> Date:Fri, 22 Jan 2010 08:07:03 +0100
> From:Michael van Elst
> Message-ID: <20100122070702.ga10...@serpens.de>
>
> | except that there a lot of assumptions that
> | physical block size is the same as DE
k...@munnari.oz.au (Robert Elz) writes:
>Like most things, there is no universal correct answer here, simply
>deciding "always use bytes" because it seems simpler is unlikely to be
>the overall best answer.
I think the suggestion is to use block numbers (or some other form
of addressing larger un
On Fri, Jan 22, 2010 at 02:06:27PM +0700, Robert Elz wrote:
> One place where that's currently not true is in the quote files,
> there block counts are in blocks, and are 32 bits
For FFS/UFS v1 it doesn't matter as filesystem blocks are 32bit and
relative to the fragment size. For FFS2 it doesn't
Date:Fri, 22 Jan 2010 08:07:03 +0100
From:Michael van Elst
Message-ID: <20100122070702.ga10...@serpens.de>
| except that there a lot of assumptions that
| physical block size is the same as DEV_BSIZE.
Is that really true these days? I believe there are assumpti
On Fri, Jan 22, 2010 at 05:46:31AM +, David Holland wrote:
> On Thu, Jan 21, 2010 at 10:30:20PM +, Michael van Elst wrote:
> > IMHO there need to be three different ways to specify block
> > offsets and block counts:
> >
> > 1. in units of blocks of the physical device
> > 2. in units
Date:Fri, 22 Jan 2010 05:46:31 +
From:David Holland
Message-ID: <20100122054631.gc23...@netbsd.org>
| Since in practice nothing can be larger than the maximum value of
| off_t anyway, and all counts should be getting carried around as
| 64-bit values, using
On Wed, Jan 20, 2010 at 11:14:38AM +0900, Masao Uebayashi wrote:
> > Too bad we don't have a geenric SPLASSERT() for this kind of stuff ...
>
> It's surprising to me we've not had SPLASSERT() now. I think SPLASSERT() is
> possible if we don't make it generic; make it a nop on platforms which
On Thu, Jan 21, 2010 at 10:30:20PM +, Michael van Elst wrote:
> IMHO there need to be three different ways to specify block
> offsets and block counts:
>
> 1. in units of blocks of the physical device
> 2. in units of blocks of DEV_BSIZE bytes
> 3. in bytes
Don't forget: 4. in units of
On Tue, Jan 12, 2010 at 08:48:21PM +0100, Matthias Drochner wrote:
> But I think there is a more general problem: The driver reads a pointer
> which can become invalid immediately after the lock is released, no
> matter how the locking is done. Or am I missing something?
No, that is a problem affe
Hello,
disk devices are accessed in units of 'blocks', a block can be
any size, however NetBSD makes assumptions in many places that
a block is 512 bytes or DEV_BSIZE bytes which makes it impossible
to use devices with different block sizes.
IMHO there need to be three different ways to specify
On Tue, Jan 19, 2010 at 10:52:49PM +0100, Manuel Bouyer wrote:
> On Tue, Jan 19, 2010 at 10:43:04PM +0100, Manuel Bouyer wrote:
> > [...]
> > If not, dk.c needs to be fixed to raise to splbio() in its done routine.
> > raidcframe already does it. I suspect ccdiodone() and vndiodone()
> > need it to
I found the answer -- sorry for the noise :-)
SOFTINT(9)
The kernel does not allow software interrupts to use facilities or per-
form actions that are likely to block for a significant amount of time.
This means that it's not valid for a software interrupt to sleep on con-
dition va
12 matches
Mail list logo
