ng thread.
Is there some documentation on how "fast" software interrupts works ?
what happens to the borrowed thread when the soft interrupt handler
wants to sleep ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
very cache_lookup()
which already has a reference.
Not sure which one is cheaper.
Of course cache_lookup_raw() has the same issue.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Jan 08, 2010 at 03:29:05PM +0100, Ignatios Souvatzis wrote:
> About [LBA28 boundary crossing]
>
> Has something eben done about this?
Commited in HEAD, not yet pulled up to netbsd-5 AFAIK.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
is still wrong. rlim_cur is a int, so storing a
64bit value, possibly larger than 4Gb in a 32bit int will cause trouble.
In this case the overflow needs to be detected and a sensible value
needs to be used instead. Otherwise, you may end up with a very low RSS
limit preventing userland from running
ever bothered to check it.
>
> I think you should cap the RSS limit ar VM_MAXUSER_ADDRESS in case someone
> ever enhances UVM to track RSS. There is little point in having more
> pages resident than you are allowed to address.
Seconded
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
e xfer in
[eou]hci_device_intr_abort() and [eou]hci_root_intr_abort()
when the xfer to be aborted is the pipe's intrxfer.
I went through the device drivers and it looks safe, as nothing
gets a cached value of pipe->intrxfer.
Comments ?
--
Manuel Bouyer
NetBSD: 26 ans d'ex
On Tue, Jan 12, 2010 at 09:13:58PM -0800, Tom Spindler wrote:
> Is kern/42560 related?
I don't think so; the problem I found is specific to interrupt pipe.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
x27;s intrxfer.
>
> Just for symmetry - can't this be done in usbd_abort_pipe(),
> preferrably outside the splusb()?
Are we sure nothing will change pipe->intrxfer under us outside of splusb ?
If so the attached patch should be safe, but I find it even uglier than the
previous
On Wed, Jan 13, 2010 at 10:45:29AM +, David Holland wrote:
> On Thu, Dec 17, 2009 at 10:29:13PM +0100, Manuel Bouyer wrote:
> > I got a look again at the ufs_rename patch that David Holland sent
> > at the end of september, and managed to get it working on netbsd-5.
>
&
f so, that's the same as I get with that patch
> applied. (Don't merge that patch; the locking assertions are
> unportable/illegal.)
Ok, I'll remove it from my tree then.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Jan 13, 2010 at 12:19:28PM +0100, Manuel Bouyer wrote:
> On Tue, Jan 12, 2010 at 09:32:50PM +0100, Matthias Drochner wrote:
> >
> > bou...@antioche.eu.org said:
> > > The attached patch fixes this by freeing the xfer in
> > > [eou]hci_device_intr_abo
perly.
>
> I would like to get some ideas how this should be done
> in NetBSD. Any ideas ?
Look at the *FIXUP options.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ow this should be done
> > > in NetBSD. Any ideas ?
> >
> > Look at the *FIXUP options.
>
> How does the PCI_ADDR_FIXUP exactly work?
I think they do reprogram the BAR based on the kernel's knowledge of
allocated memory ranges. You'd have to check the sources.
&
On Tue, Jan 19, 2010 at 12:57:30PM -0600, David Young wrote:
> On Tue, Jan 19, 2010 at 12:57:57PM +0100, Manuel Bouyer wrote:
> > On Tue, Jan 19, 2010 at 12:50:55PM +0100, Christoph Egger wrote:
> > > Why are the *FIXUP options disabled by default in x86 kernels?
> >
>
fixed to raise to splbio() in its done routine.
raidcframe already does it. I suspect ccdiodone() and vndiodone()
need it too.
cgdiodone() definitively needs it as the comment says it needs to be called
at splbio.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
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 too.
Maybe not; it seems ccd is MP-safe.
For vnd, the lack of
On Tue, Jan 19, 2010 at 05:10:29PM -0500, Thor Lancelot Simon wrote:
> On Tue, Jan 19, 2010 at 10:52:49PM +0100, Manuel Bouyer wrote:
> >
> > The buffer queue could be corrupted here, because of this.
>
> I think this stuff should all be mutex-protected. For what othe
On Tue, Jan 19, 2010 at 05:19:07PM -0500, Thor Lancelot Simon wrote:
> On Tue, Jan 19, 2010 at 11:16:41PM +0100, Manuel Bouyer wrote:
> [I wrote]
> > > I think this stuff should all be mutex-protected. For what other
> > > reason do we need splbio/splvm in here any more?
On Tue, Jan 19, 2010 at 10:46:26PM +, Mindaugas Rasiukevicius wrote:
> 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.
> > > r
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 vn
ing under sources
> from a day or so ago, and from early January.
>
> Does anyone have any thoughts?
could you see if this pullup:
http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1269
fixes it ?
Note that the patch is only for wd.c, for vnd, cgd and dk you'll have
to extract the
cgd1: error 5
> xbd IO domain 1: error 5
It seems raidframe doesn't do anything special for memory failure.
It returns EIO for the whole request if it can't get an entry
from bufio_cache for I/O to one component. Maybe it should wait and
retry to I/O later ?
dk(4) does this ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Jan 26, 2010 at 07:02:23PM +0100, Christoph Badura wrote:
> On Tue, Jan 26, 2010 at 03:32:23PM +0100, Manuel Bouyer wrote:
> > Can you give more details on the corruption ?
> > Was it only directory entries that were corrupted, or did you notice
> > corruptions
ache.
I think vclean() should also take care of removing the vnode from
the buffer cache's hash. Comments ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Jan 31, 2010 at 12:35:16AM +0100, Manuel Bouyer wrote:
> Hi,
> while investigating directory corruption on my NFS server I found
> a possible issue with the buffer cache.
>
> The buffer cache keeps a hash of buf_t, the key being (vp, bp->b_lblkno).
> This allows, fo
140.
Now I don't know where to go, as I don't know the details of UBC internals.
Can anyone help ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Jan 31, 2010 at 11:33:47PM +0100, Manuel Bouyer wrote:
> hi,
> I need some help with the reproductible issue reported in kern/35704.
> This also happens with NetBSD 5.0_STABLE, and filling up the filesystem
> isn't required: being overquota is enough.
> I reproduced
On Tue, Feb 02, 2010 at 06:10:59PM +0100, Manuel Bouyer wrote:
> I made some progress on this.
> It seems that UFS_TRUNCATE() isn't doing anything UBC-related in this case,
> the pages allocated do still contain data previsouly written (the write
> error doesn't occur on a
ith a -current kernel (both native and Xen).
Any idea of what fixed it in -HEAD, and if it can be pulled up to netbsd-5 ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
PAE kernel). We would have to split
> pd_entry_t from paddr_t, which is currently not the case.
Sure, you can't change the hardware to make the formats the same :)
I don't know if anything outside kernel tries to read the PTE though.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ev/ (paddr_t vs unsigned
> long issues). Question is: should it be added to ALL for additional checks?
I think so. Such issues should be fixed in MI code anyway. paddr_t !=
unsigned long is something we want to support.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
m_t)uvmexp.free) is less error-prone (again, risk of overflow
> with free > 4GB).
Yes, and clamped to VM_MAXUSER_ADDRESS if too large, in the i386 case.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Feb 24, 2010 at 12:18:13AM +0100, Jean-Yves Migeon wrote:
> On 02/23/10 20:15, Manuel Bouyer wrote:
> > On Tue, Feb 23, 2010 at 04:57:55PM +0100, Jean-Yves Migeon wrote:
> >> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and
> >> no
On Wed, Feb 24, 2010 at 11:59:33AM +, Andrew Doran wrote:
> On Wed, Feb 24, 2010 at 10:16:56AM +0100, Manuel Bouyer wrote:
>
> > I'm not sure what the effect to configure and similar scripts would be.
> > If this is for modules, I think this needs more though. I suspec
BI is more real than
> what the unlucky would want to believe.
And it also stops working because of unrelated changes in the kernel ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Feb 24, 2010 at 03:51:00PM -0800, Jason Thorpe wrote:
>
> On Feb 24, 2010, at 1:16 AM, Manuel Bouyer wrote:
>
> > I'm not sure what the effect to configure and similar scripts would be.
> > If this is for modules, I think this needs more though. I suspect som
e same.
Maybe atari vs mac68k was not the best example; if you look at
mac68k vs sun3 you'll find differences in macros and inline functions
in pmap.h
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
gets stuck in BIOS, and on wakeup after a
suspend/standby, the kernel is completely dead. But that's a different
problem.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: apm.c
==
etbsd-5 amd64 dom0 kernel built a week ago.
the is the i386 port you're using PAE or non-PAE (if it's a
Xen 3.3.1 i386, it's most probably PAE) ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
n kernel,
> but i386 and xen have the same $MACHINE, don't they?
they have, although it would make sense to make it different.
The main problem would be configure scripts that may not parse properly
a different $MACHINE.
>
> Probably you should mention kernel modules for su
part of the
API can be used in a module and which cannot.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
also needed for -4 (AFAIK it's older than -3). But I've not
had a chance to test it yet ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
> 17:11:08 EET 2010 r...@jadis:/tmp/nb5/obj/sys/arch/amd64/compile/XEN3_DOM0
> amd64
But you could try a i386-PAE dom0 kernel with a amd64 hypervisor.
This is supposed to work (and the hypervisor would see the full
memory, and allow to run amd64 guests). This would be an interesting
test.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Mar 04, 2010 at 12:04:45PM -0600, David Young wrote:
> On Fri, Feb 26, 2010 at 11:59:46AM +0100, Manuel Bouyer wrote:
> > PS: on this laptop the pfm handler are harmfull and I had to disable them:
> > on reboot, the laptop gets stuck in BIOS, and on wakeup after a
> >
rather than stealing them from many small files?
I think it uses a simple LRU scheme, but that would need to be confirmed
from sources (or someone knowning the details :)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
I also have the same requirements, for some various kind of devices
(serial, USB, even some disk devices)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Mar 08, 2010 at 01:17:48AM +0100, Martin Husemann wrote:
> On Mon, Mar 08, 2010 at 01:16:04AM +0100, Martin Husemann wrote:
> > doesn't "boot -v" provide you with that sort of output?
>
> I guess I meant -x
I tried both -v and -x and none print anything abou
).
Linux udev can handle this, and it's usefull (I've got do to such
special setups at work a few time already).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
would be faster ?
My guess is that the time is not spent in the syscall code itself,
but in the socket code (or TCP).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
b6
db{0}> mach cpu 7
using CPU 7
db{0}> tr
x86_pause() at netbsd:x86_pause
mutex_vector_enter() at netbsd:mutex_vector_enter+0xf6
cv_timedwait_sig() at netbsd:cv_timedwait_sig+0x132
sowait() at netbsd:sowait+0x52
do_sys_accept() at netbsd:do_sys_accept+0x146
sys_accept() at netbsd:sys_accept+0x28
syscall() at
On Fri, Mar 19, 2010 at 02:16:26PM +, Andrew Doran wrote:
> On Fri, Mar 19, 2010 at 12:38:12PM +0100, Manuel Bouyer wrote:
> > Hi,
> > last night I got the panic below on a fairly busy ftp/http server
> > (serving static content). The kernel is 5.0_STABLE from Jan, 19.
&g
can run
> for days. If set to RAID (I'm simply mirroring two 1 TB drives), it might
> finish a newfs and untargzip a set, but never all of them.
How old is your kernel ? I've had strange issues with ahci and
interrupts on some machines, and a fix (or rather a workaround) for this
has
bufio_cache, PR_NOWAIT).
Does anyone see if this can sleep somewhere despite the PR_NOWAIT ?
Maybe in some low-level UVM or pmap operation ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
VOP_STRATEGY should be called with process context (kthread, user).
> Anyhow that's unlikely to fix your problem.
dkiodone() is always called from thread or software interrupt context, isn't
that enough ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
problem).
The "tbp != bp" has not fired today, but I guess it's because the
load is sighly smaller than a working day.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: dk.c
=
m = mnew;
goto mbufcopied;
} else {
MEXTADD(mnew, jbuf->buf, NFE_JBYTES, 0, nfe_jfre
[...]
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
speed reasons?
No idea.
> Damien Bergamini warned me there would
> likely be alignment issues.
If you use mbuf clusters, the storage will be aligned to 2k (size of
a mbuf cluster storage). I don't think it can be an issue.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
fers.
If you're doing the dma to arbitrary memory, the bus_dma call will check if
it's dma_safe and if it's not, will allocate bounce buffers and
copy data from/to it.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Do you have a stack trace ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
> The output from 'ps asx':
>
> 0 619 5390 11 117 0 7552 796 tstile DttyE0
> 0:00.00 disklabel sd0
I would guess the device returns an error which is not properly
handled. can you get a stack trace of the disklabel process in
the kernel ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
t; vn_open+0x1fc
> sys_open+0xd7
> syscall+0xaa
>
> Christoph
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
so yes, it actually seems to wait for this lock.
Now the challenge is to find who is holding it. If you can examine the
struct mutex, you should find the address of the lwp holding it ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Mar 19, 2010 at 04:25:15PM +0100, Manuel Bouyer wrote:
> On Fri, Mar 19, 2010 at 02:16:26PM +, Andrew Doran wrote:
> > On Fri, Mar 19, 2010 at 12:38:12PM +0100, Manuel Bouyer wrote:
> > > Hi,
> > > last night I got the panic below on a fairly busy ftp/http s
On Sun, Apr 18, 2010 at 02:51:38PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > >
> > > AFAIK syncache is not using callout_halt(). It's testing callout_invoking
> > > () though.
> > > I can't say if droping the softnet
On Mon, Apr 19, 2010 at 12:55:21PM +0200, Manuel Bouyer wrote:
> > There are multiple paths calling syn_cache_put() and not only SYN cache,
> > but also upper TCP layers and IP would need to be inspected. Unlikely to
> > be safe and unlikely to be trivial to re-structure to
On Mon, Apr 19, 2010 at 02:09:43PM +0200, Manuel Bouyer wrote:
> On Mon, Apr 19, 2010 at 12:55:21PM +0200, Manuel Bouyer wrote:
> > > There are multiple paths calling syn_cache_put() and not only SYN cache,
> > > but also upper TCP layers and IP would need to be inspected.
On Mon, Apr 19, 2010 at 02:41:42PM +0200, Manuel Bouyer wrote:
> > That won't work well, because syn_cache_put() is called from
> > syn_cache_timer(). In addition syn_cache_rm() which does a callout_stop
> > is always called before syn_cache_put(), or syn_cache_put() is call
ieve() and sosend() where it's an optimization.
OK, so the comment was wrong :)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ion.
How would you do that ? callout_reset(&(sc)->sc_timer, 1, ...) ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
nsafe, you need
> > to keep it.
>
> s/callout_stop()/callout_halt()/ ?
No, callout_halt() would need to drop the softnet_lock. This is the problem,
and also why we need to defer freeing the syn cache entries.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Apr 19, 2010 at 04:22:29PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > On Mon, Apr 19, 2010 at 04:10:15PM +0100, Mindaugas Rasiukevicius wrote:
> > > To answer your previous question - yes, that is what I meant, plus other
> > > amendments y
On Mon, Apr 19, 2010 at 05:45:50PM +0200, Manuel Bouyer wrote:
> OK, so I modified the patch as attached. This seems to work well with
> my test setup.
I also installed this patch on the server that showed the problem. After
12 hours:
217612 SYN cache entries added
de into code that is always compiled, but only used under
> certain circumstances?
No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which
adds in the kernel table of strings for vendor/device names,
extended error codes, etc ...
--
Manuel Bouyer
NetBSD: 26 ans d'expe
r do I need memory barriers as well, or what?
You need memory barriers, modern CPUs can do speculative reads, and some
can reorder writes. AFAIK, lock operations act as memory barriers.
atomic ops do not.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
the discarding
> oversize frame. Sometimes the len in the oversize frame message
> is len=-1.
is it possible that the re device is writting past its buffer (via DMA) and
overwriting random memory ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
at netbsd:sys_reboot+0x74
syscall(ce8fbd48,b3,ab,1f,1f,1,d,bfbfeee8,0,256) at netbsd:syscall+0xc8
I'm not sure how it's supposed to work, but I guess that dkclose()
should release the parent's lock before calling vn_close() on the
parent ? Would the attached patch be correct
lade system I'd expect the NIC to have a SERDES interface, and no
phy (the chip is identified as 1000base-SX which confirm this).
It looks like the driver just can't deal with this variant of the
5709 ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
command.
there's another option, which is to fix the result of the INQUIRY command
returned to the scsipi layer, in the ciss driver (pathing the ANSII
value to 2). I think this would be the cleanest way.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Aug 29, 2010 at 01:36:36PM -0600, Michael L. Hitch wrote:
> On Sun, 29 Aug 2010, Manuel Bouyer wrote:
>
> >there's another option, which is to fix the result of the INQUIRY command
> >returned to the scsipi layer, in the ciss driver (pathing the ANSII
> >value
TNF build cluster producing binary snapshots is
down at this time and needs physical presence, we hope it will be back up
today or tomorow).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
t.
I'm probably missing something (I can't believe x86 avoided the issue
by luck for so long), can someone helps me ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Sep 22, 2010 at 01:42:04PM +0200, Manuel Bouyer wrote:
> Hello,
> I have a question about software interrupt threads (__HAVE_FAST_SOFTINTS
> case). I'm interrested in the mips implementation but I looked at x86
> and didn't find what I looked for either, so my ques
is on a serial device (and there's no keyboard/mouse at this time).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
hould look for device properties and bail if we don't
> find what we need.
looks reasonable.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
e htole*/letoh* macros have been designed from the ntoh*/hton* ones.
It's not something new and you can't blame some recent x86-centric design
for this (I suspect it's actually a vax-centric design, from history :)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Nov 17, 2010 at 11:38:54AM +0100, Johnny Billquist wrote:
> Ouch. Should I also file bugs for mutexes that are released, but
> already appear to be free?
Yes.
> Because that also happens.
LOCKDEBUG should detect this, I guess.
--
Manuel Bouyer
NetBSD: 26 ans d'exp
ng = l;
}
be instead:
if (l->l_target_cpu != NULL) {
KASSERT(spc->spc_migrating == NULL);
spc->spc_migrating = l;
}
I did the above change and it seems to work, ca
records out
> 4096 bytes transferred in 6.929 secs (5911386 bytes/sec)
what does 'dd if=myfile of=/dev/null bs=64k' shows ?
Also, what RAID level is it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
various values).
Linux uses a radix tree for this, and I coudln't come up with a better idea :)
Do we have a generic enough radix implementation somewhere wich could be
used for this ? We already use it for network routing table, but it
didn't look generic to me.
--
Manuel Bouyer
Ne
On Sun, Nov 28, 2010 at 11:02:59AM -0600, Ted Lemon wrote:
> On Nov 28, 2010, at 10:53 AM, Manuel Bouyer wrote:
> > Do we have a generic enough radix implementation somewhere wich could be
> > used for this ? We already use it for network routing table, but it
> > didn
On Sun, Nov 28, 2010 at 06:08:48PM +0100, Ignatios Souvatzis wrote:
> hi,
>
> On Sun, Nov 28, 2010 at 05:53:59PM +0100, Manuel Bouyer wrote:
> > Hello,
> > our FFS quota system is pretty outdated and is less and less suitable
> > for modern storage (quotacheck is long
On Sun, Nov 28, 2010 at 11:10:32AM -0600, Ted Lemon wrote:
> On Nov 28, 2010, at 11:07 AM, Manuel Bouyer wrote:
> > You're suggesting I should include Berkeley DB in the kernel, right ?
>
> No, wouldn't the kernel just deliver UIDs and usages?
Yes, but this needs to
On Sun, Nov 28, 2010 at 05:21:52PM +, Sad Clouds wrote:
> On Sun, 28 Nov 2010 17:53:59 +0100
> Manuel Bouyer wrote:
>
> > One open question is how to store quota informations on disk.
> > At this time we use one big array indexed by uid or gid. This can
> > be
is that you can't integrate it with
WAPBL (which is one of the goals for the new implementation).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Nov 28, 2010 at 05:40:15PM +, Sad Clouds wrote:
> On Sun, 28 Nov 2010 18:27:07 +0100
> Manuel Bouyer wrote:
>
> > > Wouldn't a hash table work?
> >
> > I think it's too dependant on uid distribution, or even how much uid you
> > have.
quote info in the block - a more intelligent hash function, with a scan
> when the block is read to find the appropriate entry and dbm style block
> splitting on overflow ought to work reasonably well, and not be either
> large or costly.
I'll have to see how dbm works. I'm not sure it's better than a radix
tree though.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
.
b) the limits are keep in arbitrary place. This means that limits cannot
be enforced as soon as the filesystem is mounted read/write, but
at a later time, after all filesystems have been mounted when the
equivalent of 'quotaon' is run. For ephemeral filesystems it's not
much
On Sun, Nov 28, 2010 at 09:34:29PM +, David Laight wrote:
> On Sun, Nov 28, 2010 at 06:27:07PM +0100, Manuel Bouyer wrote:
> > > Wouldn't a hash table work?
> >
> > I think it's too dependant on uid distribution, or even how much uid you
> > have. a tre
/sec)
>
>
> The volume is RAID-1. I wonder why the NetBSD driver is not in sync
> with the FreeBSD one as that appers to be actively maintained.
because the kernel interfaces are completely different; porting require
a substancial effort, and hardware for tests.
--
Manuel Bouyer
On Thu, Dec 16, 2010 at 03:13:33PM +0100, Christoph Egger wrote:
>
> Hi!
>
> When I start a xen guest I get this message:
>
> xbdback backend/vbd/1/832: can't VOP_OPEN device 0xe13: 16
16 is EBUSY. is it a HVM guest, or a PV guest ?
Also, you didn't mention which Ne
1 - 100 of 796 matches
Mail list logo
