On Thu, May 31, 2012 at 07:52:38AM +0200, Emmanuel Dreyfus wrote:
> The ENOMEM is raised in uvm_map_prepare(), here:
But I now strongly suspect that there is a memory leak somewhere:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
205 root 370 1832M 134M RUN
Recently we found out (PR kern/46463) that kqueue() file descriptors, which
originaly were designed to be "local process only" objects, could be passed
with SCM_RIGHTS messages to other processes. They probably can not be
transfered any other way (i.e. on fork() they are not inherited). So this
loo
Hello,
I tried reusing the secsize from getdisksize() in place of DEV_BSIZE.
After correcting for a resulting divide-by-zero, I get further, but only
by a fraction.
The disk in question (model: WD7500AARX; "750GB") has a GPT with one
partition which spans as much as possible of the disk:
#
On Thu, May 31, 2012 at 07:52:38AM +0200, Emmanuel Dreyfus wrote:
> I get ENOMEM doing this (stacksize = 262144, pu->pu_cc_stackshift = 18):
>
> sp = mmap(NULL, stacksize, PROT_READ|PROT_WRITE,
> MAP_ANON|MAP_PRIVATE|MAP_ALIGNED(pu->pu_cc_stackshift), -1, 0);
Just a side not
On Thu, May 31, 2012 at 01:08:44PM +0200, Jan Danielsson wrote:
>
>If dd on the cgd device appears to be working fine, the drive is
> perfectly usable if I use it without a cgd device -- what should I be
> looking at?
>
>For completeness, "gpt create cgd3" returns:
>
>gpt: unable to
On Wed, 30 May 2012 22:43:14 +0200, Lars Heidieker wrote:
Well, if I read the patch right the transfer_xcall will be called
from
pool_drain_start and be waited for in pool_drain_end and therefor
calling the other xcall in pool_cache_invalidate that will release
the
per cpu cached objects dire
Walking a directory tree (e.g. during a backup) unnecessarily updates atimes.
Mounting -o noatime is not an option because the atime updates are needed
elsewhere.
Is there an option (overlay mount or such) to present a file system noatime
(or even read-only) to one process (or at one mount point) b
A null mount should do the job and this fstab entry should work:
/path/to/orig /path/to/ovarlay null ro,noatime
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On May 31, 2012, at 2:14 PM, Edgar Fuß wrote:
> Walking a directory tree (e.g. during a backup
> A null mount should do the job and this fstab entry should work:
>
> /path/to/orig /path/to/ov[e]rlay null ro,noatime
Unfortunately, that doesn't work. I get
mount_null: -o atime: option not supported
(yes, that's "atime", not "noatime").
Just mounting ro doesn't seem to stop the
On Thu, May 31, 2012 at 04:23:12PM +0200, Edgar Fuß wrote:
> > A null mount should do the job and this fstab entry should work:
> >
> > /path/to/orig /path/to/ov[e]rlay null ro,noatime
> Unfortunately, that doesn't work. I get
> mount_null: -o atime: option not supported
> (yes, that's
> Recently we found out (PR kern/46463) that kqueue() file descriptors,
> which originaly were designed to be "local process only" objects,
> could be passed with SCM_RIGHTS messages to other processes. [...]
> I propose to not allow sending kqueue file descriptors [...]
> Or are there any legit
> I would think that the atime updates are generated by
> mount_null/nullfs when the corresponding file in the null-mount
> is accessed and the nullfs has to access the original file.
Yes, probably.
> How about using fss for it instead.
1. fss is still marked experimental.
2. does fss work with WA
On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
> > How about using fss for it instead.
> 1. fss is still marked experimental.
oh, I have overlooked that.
> 2. does fss work with WAPL at all?
I don't know that.
Another idea is, if lvm is considered stable, to create a low-level
snapsho
On Thu, 31 May 2012, Matthias Kretschmer wrote:
On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
How about using fss for it instead.
1. fss is still marked experimental.
oh, I have overlooked that.
2. does fss work with WAPL at all?
I don't know that.
It seems to work for me!
Hello,
Although it's useful to mount random media more safely than it would be
using kernel-space, I noticed that using 64KB reads, the kernel cd9660
will gladly read ~20MB/s from a DVD, but that rump_cd9660 using
64KB reads is limited to aproximately 4MB/s at most, even if the system
is mostly id
On Mon, 28 May 2012 06:51:43 -0700 (PDT)
Paul Goyette wrote:
> I _do_ like part 2 of your proposal - linking the "core" kernel first,
> and then re-linking with selected modules.
I also think that this would be very nice
--
Matt
On Thu, 31 May 2012 10:38:38 -0400 (EDT)
Mouse wrote:
> > Recently we found out (PR kern/46463) that kqueue() file descriptors,
> > which originaly were designed to be "local process only" objects,
> > could be passed with SCM_RIGHTS messages to other processes. [...]
>
> > I propose to not all
On Thu, 31 May 2012 14:40:44 -0400
Matthew Mondor wrote:
> What I can see is that the implications of inheriting this special
> descriptor are quite more complex than for normal FDs... Which makes
> me think that it very well could be a design decision not to inherit
> these, in which case I don
On Thu, May 31, 2012 at 08:37:06AM -0700, Paul Goyette wrote:
> On Thu, 31 May 2012, Matthias Kretschmer wrote:
>
> >On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote:
> >>>How about using fss for it instead.
> >>1. fss is still marked experimental.
> >oh, I have overlooked that.
> >
> >>2
19 matches
Mail list logo
