:
:Any plan to MFC? I am interesting to see it in 4.3-RELEASE.
:
:--
:David Xu
It will definitely not go in until after the release. It's still
experimental (in our tree).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubsc
If memory serves me right, David Xu wrote:
[dirpref stuff]
> Any plan to MFC? I am interesting to see it in 4.3-RELEASE.
I'm pretty sure it won't be in 4.3-RELEASE. In case you didn't realize,
RELENG_4 has been in code freeze for some weeks now, preparing for a
release next week. "Code freeze
Hello Matt,
Wednesday, April 11, 2001, 2:24:35 AM, you wrote:
:>> I'm not 100% convinced about the algorithm to avoid clusters filling
:>> up with directory-only entries (it looks like a worst-case would fill
:>> a cluster with 50% directories and 50% files leaving a bad layout when
:>> the d
> Yup, Kirk committed it. I really like the changes -- in the old days
> disk caches were tiny and directories were not well cached on top of that.
> It made sense to try to keep directories close to their files.
So I'm all excited now at the progress that ufs/ffs are making recently
On 10-Apr-01 Niels Chr. Bank-Pedersen wrote:
>
> Is it me fsck'ing up, or is fsck(8) lacking behind in the
> dirpref changes?
>
>
> Automatic boot in progress...
> /dev/da0s1a: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN
> FIRST ALTERNATE
>
> /dev/da0s1a: UNEXPECTED
Is it me fsck'ing up, or is fsck(8) lacking behind in the
dirpref changes?
Automatic boot in progress...
/dev/da0s1a: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
ALTERNATE
/dev/da0s1a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/da0s1a: Automatic file s
:Why VMIO dir works better if directories are placed close to each other? I
:think it only makes the cache data of an individual directory stay in the
:memory longer. Is there a way to measure the effectiveness of the disk
:drive's cache?
:
:-Zhihui
I wasn't being clear enough. There are tw
> Why VMIO dir works better if directories are placed close to each other? I
> think it only makes the cache data of an individual directory stay in the
> memory longer. Is there a way to measure the effectiveness of the disk
> drive's cache?
The real performance gain is seen when doing stuff wi
On Tue, 10 Apr 2001, Matt Dillon wrote:
> :> I'm not 100% convinced about the algorithm to avoid clusters filling
> :> up with directory-only entries (it looks like a worst-case would fill
> :> a cluster with 50% directories and 50% files leaving a bad layout when
> :> the directories are po
:> I'm not 100% convinced about the algorithm to avoid clusters filling
:> up with directory-only entries (it looks like a worst-case would fill
:> a cluster with 50% directories and 50% files leaving a bad layout when
:> the directories are populated further), but then the non-dirpref
:> sche
On Mon, Apr 09, 2001 at 08:49:59PM -0700, Rodney W. Grimes wrote:
> > Question: Does the rpcbind program in -current have the same problem
> > or has it already been fixed by whomever you imported the code from?
> > (If it hasn't been fixed I'll be happy to fix it. I'm hoping it has,
According to Cameron Grant:
> fix just committed, sys/dev/sound/isa/ad1816.c rev 1.18.
>
> you must be the only freebsd user on the planet with an ad1816. :)
Works fine BTW, thanks to you two.
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
FreeBSD caerdonn.eurocontrol.fr 5
According to Cameron Grant:
> fix just committed, sys/dev/sound/isa/ad1816.c rev 1.18.
>
> you must be the only freebsd user on the planet with an ad1816. :)
That's what I was thinking :)
Thanks, I'll just reboot now to test the patch.
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL
> Stopped at _mtx_lock_sleep+0x2e2: movb 0x1d5(%edx),%al
> _mtx_lock_sleep
> snd_mtxlock
> ad1816_lock
fix just committed, sys/dev/sound/isa/ad1816.c rev 1.18.
you must be the only freebsd user on the planet with an ad1816. :)
-cg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
On Tue, 10 Apr 2001, Ollivier Robert wrote:
> Stopped at _mtx_lock_sleep+0x2e2: movb 0x1d5(%edx),%al
> _mtx_lock_sleep
> snd_mtxlock
> ad1816_lock
Following patch should fix, I'll commit this to -current later.
- greid
Index: ad1816.c
=
I systematically get the following panic since the end of March at boot
time:
Kernel trap 12 with interrupt disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x65656e48XXX een8 XXX
fault code = supervisor read, page not present
ins
[.]
> > The second improvement, contributed by
> > [EMAIL PROTECTED], is a new directory allocation policy (codenamed
> > "dirpref"). Coupled with soft updates, the new dirpref code offers up
> > to a 60x speed increase in gluk's tests, documented here:"
> >
> >
>ht
17 matches
Mail list logo
