On Tue, Oct 23, 2012 at 07:53:28PM +0200, Edgar Fu? wrote:
> > the output of ps -lax on the NFS server during the 18-20 second window
>
> As far as I remember (you need the s option, too), the main nfsd
> thread is on select, one subthread on biowait or biolock and the
> others on tstile.
It
On Sun, Nov 04, 2012 at 06:54:57AM +0100, Emmanuel Dreyfus wrote:
> But that cannot handle negative caching. FUSE allows the filesystem to
> specify a TTL for a ENOENT. I cannot implement it at the PUFFS level
> like I did before, since there is no struct puffs_node associated with
> an unexist
On Tue, Nov 06, 2012 at 11:16:29PM +0100, Edgar Fu? wrote:
> So, while investigating my WAPL performance problems, It looks like I can
> crash the machine (not reliably, but more often that not) with a simple
> seq 1 3000 |?xargs mkdir
> command. I get the following backtrace in ddb (wetw
On Wed, Nov 07, 2012 at 11:34:08AM +0100, Edgar Fu? wrote:
> > wapbl_register_inode shouldn't be able to reach that panic...
> Maybe that's some stack frame optimization.
Well... as far as I can tell wapbl_register_inode does not call
wapbl_register_deallocation, so it shouldn't be. But maybe dd
On Wed, Nov 07, 2012 at 12:04:01PM +0100, J. Hannken-Illjes wrote:
> > ffs_truncate calls both, but mkdir shouldn't result in things being
> > released... or so I'd think.
>
> It does. Just before returning ufs_direnter() tries to short the
> directory and calls UFS_TRUNCATE() aka ffs_truncat
On Sun, Nov 11, 2012 at 08:17:26AM +0100, Emmanuel Dreyfus wrote:
> > I know this is a bike shed, and I'm sorry to be the one to bring it
> > up, but can we use the names chmodat, chownat, &c., for our native
> > system calls, and just use libc aliases or _BLAH_SOURCE nonsense or
> > something
On Sun, Nov 11, 2012 at 05:55:23AM +0100, Emmanuel Dreyfus wrote:
> >+ /*
> >+ * openat() falls back to open() behavior if
> >+ * - path is absolute XXX check this.
> >+ * - fd is AT_FDCWD
> >+ */
> >
> > Have you checked the XXX, and/or written automatic tests
On Sun, Nov 11, 2012 at 08:31:02AM +0100, Emmanuel Dreyfus wrote:
> > I don't think namei.h / vfs_lookup.c is the right place to be handling
> > file descriptors. Can you make these take vnodes, rather than file
> > descriptors, or move them into vfs_syscalls.c?
>
> I made the change, but it
On Sun, Nov 11, 2012 at 10:39:06AM +0200, Alan Barrett wrote:
> However, I also want the inconsistent POSIX names to be provided.
>
> I don't know a good way of satisfying both goals.
#if defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) /* or whatever */
int fchmodat(int, const char *, mode_
On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > Here is a patch that implements fexecve(2) for review:
> > http://ftp.espci.fr/shadow/manu/fexecve.patch
>
> This strikes me as profoundly dangerous. Among other things, it
> means you can't allow any program running in
On Thu, Nov 15, 2012 at 04:53:26PM -0500, Thor Lancelot Simon wrote:
> > > > Here is a patch that implements fexecve(2) for review:
> > > > http://ftp.espci.fr/shadow/manu/fexecve.patch
> > >
> > > This strikes me as profoundly dangerous. Among other things, it
> > > means you can't all
On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon wrote:
> > > The problem is that there is a great deal of existing code in the
> > > world which receives file descriptors and which is not designed with
> > > the possibility that they might then be used to exec.
> >
> > Then thos
On Fri, Nov 16, 2012 at 12:35:46PM +, Julian Yon wrote:
> > Meanwhile, if you can own the other end to the point where you can
> > open an executable file containing code you supplied and pass it down
> > an existing socket connection, you've already done arbitrary code
> > execution. If th
On Fri, Nov 16, 2012 at 09:13:13AM -0500, Thor Lancelot Simon wrote:
> On Fri, Nov 16, 2012 at 09:14:14AM +0000, David Holland wrote:
> > On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon wrote:
> >
> > Well, no. You have to first receive a new file descripto
On Sat, Nov 17, 2012 at 06:42:50PM -0500, Thor Lancelot Simon wrote:
> > O_EXEC cause open()/openat() to fail if the file mode does not grant
> > execute rights
> >
> > There are security concerns with fd passed to chrooted processes, which
> > could help executing code. Here is a proposal f
On Sun, Nov 18, 2012 at 06:16:00PM +, David Holland wrote:
> > This appears to contradict either the description of O_EXEC in the
> > standard, or the standard's rationale for adding fexecve(). The
> > standard says O_EXEC causes the file to be open for execution
On Sun, Nov 18, 2012 at 07:42:43PM +0100, Emmanuel Dreyfus wrote:
> > The standard is clearly wrong on a number of points and doesn't match
> > the historical design and behavior of Unix. Let's either implement
> > something correct, or not implement it at all.
>
> Do you have something corre
On Sun, Nov 18, 2012 at 06:51:51PM +, David Holland wrote:
> > > This appears to contradict either the description of O_EXEC in the
> > > standard, or the standard's rationale for adding fexecve(). The
> > > standard says O_EXEC causes the fil
On Thu, Nov 22, 2012 at 08:07:14PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 22, 2012 at 11:00:34AM -0800, John Nemeth wrote:
> > Would that prevent recovering in the case where the user
> > disconnects a device (typical example is a thumb drive) and later
> > reconnects it (once we have t
On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
> If necessary, the open(2) syscall could be versioned so that
> O_RDONLY is no longer defined as zero.
This seems possibly worth doing to avoid all the annoyance with
FREAD/FWRITE vs. O_RDONLY/O_WRONLY, but I really don't see how it'
On Wed, Nov 28, 2012 at 03:12:36PM +, David Holland wrote:
> On Mon, Nov 26, 2012 at 01:49:09AM +0300, Alan Barrett wrote:
> > If necessary, the open(2) syscall could be versioned so that
> > O_RDONLY is no longer defined as zero.
>
> This seems possibly worth d
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
> In short the attached diff:
>
> - Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
> restart a vnode operation once it returns ERESTARTVOP.
>
> - Changes fstrans_start() to take an optional `hint vnode
On Fri, Nov 30, 2012 at 12:00:52PM +, David Laight wrote:
> > >I must look at how to determine that disks have 4k sectors and to
> > >ensure filesystesm have 4k fragments - regardless of the fs size.
> >
> > newfs should already ensure that fragment >= sector.
>
> These disks lie about
On Sat, Dec 01, 2012 at 04:27:14PM -0500, Mouse wrote:
> Neither. The sector size claimed to the host should equal both the
> sector size on the media and the granularity of the interface.
As a consumer of block devices, I don't care about either of these
things. What I care about is the larges
On Sat, Dec 01, 2012 at 07:07:36PM -0500, Mouse wrote:
> >> Neither. The sector size claimed to the host should equal both the
> >> sector size on the media and the granularity of the interface.
> > As a consumer of block devices, I don't care about either of these
> > things. What I care abo
On Sun, Dec 02, 2012 at 01:32:17AM +, Julian Yon wrote:
> > I don't care about the block granularity of the interface. (Unless I
> > suppose it's larger than the atomic write size; but that would be
> > weird.)
>
> If it's smaller than the atomic write size that's equally weird.
> Becaus
On Thu, Nov 29, 2012 at 06:19:37PM +0100, J. Hannken-Illjes wrote:
> >> In short the attached diff:
> >>
> >> - Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
> >> restart a vnode operation once it returns ERESTARTVOP.
> >>
> >> - Changes fstrans_start() to take an opt
On Sat, Dec 01, 2012 at 11:38:55PM -0500, Mouse wrote:
> >>> things. What I care about is the largest size "sector" that will (in
> > ^^^
> >>> the ordinary course of things anyway) be written atomically.
> >> Then those are 512-byte-sector drives [...]
On Mon, Dec 03, 2012 at 12:19:58AM +, Julian Yon wrote:
> You appear to have just agreed with me, which makes me wonder what I'm
> missing, given you continue as though you disagree.
You asked why 4096-byte-sector disks accept 512-byte writes. I was
trying to explain.
> > However, we're ta
On Tue, Dec 04, 2012 at 09:26:17AM -0500, Thor Lancelot Simon wrote:
> > > And, can't you do that with traditional drives, drives which really do
> > > have 512-byte sectors? Do a 4K transfer and you write 8 physical
> > > sectors with no opportunity for any other operation to see the write
On Tue, Dec 04, 2012 at 09:59:46AM +0300, Alan Barrett wrote:
> >the genfs code also never writes clean pages to disk, even though for
> >RAID5 storage it would likely be more efficient to write clean pages
> >that are in the same stripe as dirty pages if that would avoid issuing
> >partial-str
On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote:
> > The descriptor is probably already "closed on exec" before the syscall
> > tries to use it.
>
> Nope. That happens later. I was looking through this code yesterday as
> the topic interests me. The namei lookup happens pretty earl
On Sun, Dec 02, 2012 at 05:29:01PM +0100, J. Hannken-Illjes wrote:
> I'm convinced -- having fstrans_start() return ERESTART is the way to go.
Ok then :-)
> >>> Also I wonder if there's any way to accomplish this that doesn't
> >>> require adding fstrans calls to every operation in every fs.
On Wed, Dec 05, 2012 at 01:08:14PM -0500, Mouse wrote:
> > This system call embodies a fairly fundamental shift away from the
> > Unix model that object permissions are checked when you get a handle
> > to an object -- not when you use that handle.
>
> Actually, I think that's true only of fi
On Wed, Dec 05, 2012 at 08:39:55AM -0500, Thor Lancelot Simon wrote:
> I also think we need to check, for all the fch*, fexec* syscalls:
>
> * permissions both retained from the file's open and at the time
>of use
I don't think this is necessary, any more than it is for read and
I am tired of PR 3019 and its many duplicates, so I'd like to see a
scheme that allows managing arbitrary subtrees of the filesystem
namespace in a reasonably useful manner.
The immediate application is nfs exports and mountd; however, I expect
the resulting mechanism will also be useful for handl
On Wed, Dec 05, 2012 at 04:03:40PM -0500, Mouse wrote:
> >> * whether the name in question is within the process' current
> >> root (forbidding fchdir and fchroot otherwise).
> > Definitely.
>
> I'm actually not convinced this is so obviously a good thing.
>
> I see an analogy betwee
On Thu, Dec 06, 2012 at 08:55:56AM +0700, Robert Elz wrote:
> | I am tired of PR 3019 and its many duplicates, so I'd like to see a
> | scheme that allows managing arbitrary subtrees of the filesystem
> | namespace in a reasonably useful manner.
>
> If you're going to do something like
On Thu, Dec 06, 2012 at 10:32:01AM +, Julian Yon wrote:
> I think you could take some inspiration from Linux here: it has a very
> handy umount -l which detaches the filesystem from the tree, but defers
> the rest of the unmount/cleanup until the fs is no longer busy. This
> can help in sit
sses holding the volume busy and do an ordinary umount.
The third case I guess is when vnode refcount bugs have left you with
a "busy" fs that nothing's actually using; in this case there won't be
processes hanging; but by the time you've confirmed this, there also
won
On Mon, Dec 10, 2012 at 09:36:35AM -0600, David Young wrote:
> What do people think about setting stricter guidelines for using the
> C preprocessor than the guidelines from the past?
I don't see the point; also, if your intent is to declare war on the
kernel config system we have, it'd be bette
On Mon, Dec 10, 2012 at 08:09:19AM -0800, Chuck Silvers wrote:
> the last problem I found with running the i386 1.0 "ls" on
> i386/amd64 is that some of the compat wrappers for
> getdents/getdirentries don't actually translate the data to the old
> format. the attached patch fixes that, but I'
On Mon, Dec 10, 2012 at 05:58:02PM +, paul_kon...@dell.com wrote:
> > (Also, as a side issue, at least one of your examples is invalid.
> >
> >> 1 Lazy evaluation: unlike a function call's arguments, a macro's
> >> arguments are not evaluated before the macro is "called." E.g., in
> >>
On Mon, Dec 10, 2012 at 01:16:03PM -0500, Mouse wrote:
> (Unless the "as if" rule permits it anyway, as always.)
Well yes, that's the point.
(also, after looking at it for longer, I'm now wondering what purpose
that example is supposed to serve in the first place)
--
David A. Holland
dholl...@
On Tue, Dec 11, 2012 at 01:27:09AM +, Roland C. Dowdeswell wrote:
> As an example, I often define a macro when I am using Kerberos or
> GSSAPI that looks roughly like:
>
> #ifdef K5BAIL(x) do {
> ret = x;
> if (ret) {
> /* format error mess
On Mon, Dec 31, 2012 at 02:51:16AM -0800, John Nemeth wrote:
> You need to link with libprop. I already have plans to link
> libprop to the x86 /boot for various reasons, although I haven't
> finalised how I'm going to do everything.
-r--r--r-- 1 root wheel 60588 May 25 2010 /boot
-r-
On Wed, Jan 09, 2013 at 10:15:39AM -0800, Hisashi T Fujinaka wrote:
> NetBSD documentation just kind of pointed me at figuring out which
> processes are running and looking at the backtrace. Well, the backtrace
> just looks to me like it was printing out the error. I know I should
> look at oth
The following (untested) patch reverts the defective O_SEARCH
implementation that was committed along with the *at calls back in
November.
I am currently building and testing it and will commit it when that
finishes.
I have left O_SEARCH defined and visible and made open() explicitly
ignore it.
On Sun, Jan 13, 2013 at 09:36:24AM +0100, Martin Husemann wrote:
> > build and run. I've also arranged lib/libc/c063/t_o_search.c so that
> > the tests that make use of the O_SEARCH semantics will disappear until
> > O_SEARCH comes back, and fixed some mistakes and/or incorrect hacks
> > that w
On Wed, Jan 16, 2013 at 04:24:15PM -0600, Frank Zerangue wrote:
> Migrating from 5.1.2 to 6.0.1 I have noticed many changes in the
> virtual filesystem support interface. Can anyone point me to some
> discussion or documentation of these changes?
http://www.netbsd.org/~dholland/outoftree.html
On Mon, Feb 04, 2013 at 09:39:04PM +0100, Joerg Sonnenberger wrote:
> we have quite a few tools in base that still require KVM or optionally
> support it. Removing all tools that require KVM for operation (and
> therefore setgid) is one of the open goals. It would be nice if that
> doesn't requ
On Wed, Feb 06, 2013 at 01:16:11AM +0100, Joerg Sonnenberger wrote:
> On Tue, Feb 05, 2013 at 10:25:23AM +0000, David Holland wrote:
> > On Mon, Feb 04, 2013 at 09:39:04PM +0100, Joerg Sonnenberger wrote:
> > > we have quite a few tools in base that still require
On Thu, Feb 28, 2013 at 12:40:27AM -0500, Mouse wrote:
> I'm looking at writing driver code for 5.2. A few manpages (notably
> selinit(9) and other aliases for the same page) speak of "non-MPSAFE
> drivers", but I have been unable to find what a driver has to do in
> order to be MPSAFE - nor f
On Tue, Mar 05, 2013 at 05:08:40PM +, Taylor R Campbell wrote:
> I thought that
>perhaps the device's cdevsw could provide an alternate to d_mmap,
>int?(*d_get_pagerops)(dev_t, struct?uvm_pagerops?**) or something,
>for u
On Fri, Mar 22, 2013 at 01:36:01PM +, Taylor R Campbell wrote:
> We could do the arithmetic without a macro, but it's more complicated
> to get that correct. Compare
>
> struct foo *f = alloc(offsetin(*f, f_data[n]));
>
> with
>
> struct foo *f = alloc(sizeof(*f) + sizeof(
On Wed, May 29, 2013 at 07:51:15PM +0200, Yann Sionneau wrote:
> I am wondering how I can manage virtual memory (especially how to
> avoid tlb miss, or deal with them) in exception handlers.
>
> At first my idea was to do most of the low level stuff in exception
> handlers with MMU turned off
On Mon, Jun 03, 2013 at 11:37:29AM -0400, Mouse wrote:
> At $JOB, we have two i386 machines with wm interfaces connected
> back-to-back with a short patch cable and a /30 subnet of 192.168. One
> is NFS-serving some disk space to the other over this link. They are
> running 4.0.1 (with a few
On Mon, Jun 03, 2013 at 10:11:14PM +0200, Yann Sionneau wrote:
>> There are essentially three ways to do this. Which one you chose depends
>> on the hardware.
There's also a second issue you're overlooking, which is that you need
a way to access the user address space from the kernel.
> >1) T
On Mon, Jun 03, 2013 at 11:16:25PM -0400, Matt W. Benjamin wrote:
> NFS-per se has change a lot since...NFSv4 came out. What NFS
> versions does NetBSD currently support? I had the sense that it
> probably tracked Rick Macklem's FreeBSD work at some distance...
> Like, does NetBSD support pNF
I had almost forgotten about this; but a few months back when I came
into contact with the wd TRIM support in current I wanted to change
the interface around before it appears in a release.
The current interface is two ioctls:
- first you call DIOCGDISCARDINFO; this tells you the maximum
n
As has come up many times in the past, we have a long-standing
problem, or family of problems, where in the course of operating on a
particular file system we end up not calling the file system's own
vnode or fs operations, but the root file system's operations. This
causes varying degrees of lossa
On Mon, Jun 17, 2013 at 06:48:23PM +0200, J. Hannken-Illjes wrote:
> > 1. Rename v_mount, which is the filesystem the vnode is on (almost
> > always / for device vnodes), to "v_myfs".
>
> What is wrong with this name? `v_mount' is the `struct mount' this
> vnode resides on and I don't se
On Fri, Jun 28, 2013 at 02:44:46PM +0200, Edgar Fu? wrote:
> On an NFS-mounted file system, when you try to write to a file and are
> over-quota, the write() succeeds, but a following fsync() or close() fails.
> However, when you insert a utimes() or futimes() call after the write(),
> the fsyn
On Mon, Jul 01, 2013 at 04:56:40PM +0200, Edgar Fu? wrote:
> > It's not applied to users who already have a quota entry.
> I know, thanks.
>
> The problem is something completly different from what I thought.
>
> The (Perl XS) code (mostly written by David Ho
On Sat, Jul 06, 2013 at 11:31:30AM +0200, Manuel Bouyer wrote:
> With NFS, write() can't return EDQUOT unless the write is synchronous.
> per the man page, fsync() isn't allowed to return EDQUOT either.
"allowed"
I hope that it would if that's the error that happened, rather than
pretending to
On Sat, Jul 27, 2013 at 11:52:20PM -0700, Matt Thomas wrote:
> I have several SoC targets that I've stalled on due to the need of writing
> a tty driver. Sure I could cut & paste from another driver but having to
> do that 3+ times seems inordinately stupid. So I've been thinking of
> making
On Sun, Aug 18, 2013 at 06:04:55PM +0200, Johnny Billquist wrote:
> Looking at 2.11BSD, it looks like this:
>
> struct direct {
> [snip]
>
> In NetBSD (fairly current):
>
> struct dirent {
careful, you want struct direct, not struct dirent:
struct direct {
u_int32_t d_fileno;
On Sun, Aug 18, 2013 at 12:24:12PM -0400, Mouse wrote:
> A directory may contain entries other than subdirectories. Since there
> is no enforced ordering of entries in a directory, the whole directory
> must be read to find all the subdirectories (unless 32767 subdirs are
> found first, I supp
On Mon, Aug 19, 2013 at 09:01:35AM +0200, Johnny Billquist wrote:
> >careful, you want struct direct, not struct dirent:
>
> Hmm. Probably a good point. I was wondering if NetBSD had just
> renamed direct to dirent, but that was just me getting confused
> then. (And lazy, since I didn't reall
It seems that FreeBSD's and NetBSD's ffs superblock flags have been
allowed to diverge:
-FreeBSD
+NetBSD
#define FS_UNCLEAN 0x001 /* file system not clean at mount (unused) */
#define FS_DOSOFTDEP 0x002 /* file system using soft dependencies */
#define FS_NEEDSFSCK 0x004 /* needs
On Tue, Sep 03, 2013 at 02:04:18AM +, David Holland wrote:
> FreeBSD apparently arbitrarily changed FS_INDEXDIRS when they merged
> the softupdates-journaling code,
I have adopted this change as FS_SUJ actually appears in the wild, and
FS_INDEXDIRS doesn't I think correspond
On Wed, Sep 18, 2013 at 03:34:19AM +0200, Emmanuel Dreyfus wrote:
> Christos Zoulas wrote:
>
> > On large filesystems with many files fsck can take a really long time after
> > a crash. In my personal experience power outages are much less frequent
> > than
> > crashes (I crash quite a lot
jakllsch@ and I just spent quite some time (so far unsuccessfully)
trying to figure out a hack to keep afs from deadlocking in vget().
As a consequence of this I've been looking through a bunch of the
vnode lifecycle code and my irritation level has gone past some
critical threshold.
So, here's so
On Sun, Sep 22, 2013 at 03:28:58AM +, David Holland wrote:
> So, here's some thinking out loud on the subject of fixing it.
>:
> (I also have no real idea yet how to get to where I'm describing from
> where we are in a decently incremental fashion.)
I think the
On Sat, Jun 15, 2013 at 11:56:55PM +, David Holland wrote:
> I had almost forgotten about this; but a few months back when I came
> into contact with the wd TRIM support in current I wanted to change
> the interface around before it appears in a release.
Ok, as of this writi
On Wed, Oct 09, 2013 at 11:00:53AM +0200, Marc Balmer wrote:
> My question was about source code location, the other issues raised have
> been discussed already in the past, but for the record:
Where and when? Several people have gone looking and not found this
discussion in the archives.
> lu
On Mon, Oct 14, 2013 at 03:26:19PM -0700, Paul Goyette wrote:
> >>-current is where development should take place.
> >
> >I disagree. That way - doing development in the master tree - lies the
> >madness that has given Linux some of its worst problems. Development
> >should take place on br
Did uebayasi@'s XIP work get finished/committed? Which things does it
work with? And (other than UTSL) where am I supposed to look to find
out more?
--
David A. Holland
dholl...@netbsd.org
On Tue, Oct 15, 2013 at 12:17:30AM -0700, Matt Thomas wrote:
> On Oct 14, 2013, at 11:41 PM, David Holland wrote:
> > Did uebayasi@'s XIP work get finished/committed? Which things does it
> > work with? And (other than UTSL) where am I supposed to look to find
> > o
On Fri, Oct 18, 2013 at 12:34:24AM -0700, Matt Thomas wrote:
> > If the XIP code is not mergeable, what's entailed in doing a different
> > implementation that would be? Also, is the getpages/putpages interface
> > expressive enough to allow doing this without major UVM surgery? For
> > now I'm
On Fri, Oct 18, 2013 at 09:15:33AM -0700, Matt Thomas wrote:
> >> The only problem is marking data as copy-on-write
> >> but again these pages aren't managed so the current COW code won't
> >> be happy.
> >
> > We shouldn't have to care about that unless we want to move to
> > MAP_COPY from
On Wed, Oct 23, 2013 at 01:03:16PM -0400, Jeff Read wrote:
> I was wondering if anyone was still actively working on ext3fs support
> in NetBSD. I noticed it listed in the projects page and wanted to
> synchronize my own extNfs efforts with anything currently ongoing.
To my knowledge nobody is
rmind@ points out that it's possible to create zero-length symlinks.
As zero-length symlinks aren't sensible, this should probably be
prohibited. Does anyone see any reason they shouldn't be?
(rmind wants me to post this message for some reason)
--
David A. Holland
dholl...@netbsd.org
On Fri, Nov 01, 2013 at 01:17:50PM -0400, Mouse wrote:
> > As zero-length symlinks aren't sensible, this should probably be
> > prohibited. Does anyone see any reason they shouldn't be?
>
> I think "not sensible" is not a good enough reason to prohibit
> something.
Yeah yeah, but still nowad
On Sun, Nov 03, 2013 at 07:48:54PM -0500, Mouse wrote:
> >> On Unix System V, the link command would allow hard-linking
> >> directories when used as root.
>
> Also, recently enough that at least some versions of NetBSD do it,
> unlink(2) performed by root on the last non-. link to a director
On Tue, Nov 12, 2013 at 12:43:35AM +0100, Edgar Fu? wrote:
> What the hell is this?
>
> Nov 8 05:50:29 donau /netbsd: free inode /export/home/7 had -7306144 blocks
It looks as if ffs prints that when it finds trash in the blocks field
of an inode it's allocating.
probably time to fsck :(
I
On Sun, Nov 17, 2013 at 02:02:15AM +0100, Emmanuel Dreyfus wrote:
> NetBSD-current seems to lack posix_fallocate(2)
> http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
> .html
>
> Is someone already working on it, or has thoughs about how it should be
> implemented?
I
On Sun, Nov 17, 2013 at 01:15:14PM +0700, Robert Elz wrote:
> Alternatively, the system could actually allocate all required blocks at
> the time of the posix_fallocate() call - effectively filling in any holes
> in the designated region of the file. The spec doesn't say what data is
> to be
On Sun, Nov 17, 2013 at 01:32:03PM +0100, Hubert Feyrer wrote:
> >I plan to import it and to make it available to both lua(1) and lua(4)
>
> I wonder if we really need to get all this into NetBSD,
> instead of moving it to pkgsrc somehow.
This...
--
David A. Holland
dholl...@netbsd.org
On Sun, Nov 17, 2013 at 10:24:04AM +0100, Rhialto wrote:
> > I think the chief question at this level is whether to support the
> > "keep the length" flag for fallocate, fdiscard, both, or neither. The
>
> What "keep the length" flag? I don't see one at the indicated URL.
It's a linuxism in l
On Sun, Nov 17, 2013 at 10:24:04AM +0100, Emmanuel Dreyfus wrote:
> > I think the chief question at this level is whether to support the
> > "keep the length" flag for fallocate, fdiscard, both, or neither. The
> > linux fallocate uses this to allow allocating blocks past EOF, which
> > strikes
On Sun, Nov 17, 2013 at 10:33:43AM +0100, Emmanuel Dreyfus wrote:
> > To answer both you and the Mouse - the difference is that a user process
> > actually writing data consumes measurable resources, and thus is easy to
> > find and kill. When everything happens in the kernel, spotting which
On Sat, Nov 16, 2013 at 12:40:22AM -0500, Mouse wrote:
> The documentation I have (which is consistent across 1.4T, 4.0.1, and
> 5.2) says that "[a] file I/O operation that would create a file larger
> that the process' soft limit will cause the write to fail and a signal
> SIGXFSZ to be genera
On Sun, Nov 17, 2013 at 03:46:56PM -0800, John Nemeth wrote:
> We should be able to have modules
> in pkgsrc. There are no modules in pkgsrc yet, but
There are a handful and some have been there quite a while. I believe
at least some of them are now new-style modules rather than old-style
lkms
On Tue, Nov 19, 2013 at 11:57:14AM +0100, J. Hannken-Illjes wrote:
> The attached diff will:
>
> Replace VI_INACTNOW and VI_INACTREDO with a new flag VI_CHANGING that gets
> set while a vnode changes state from active to inactive or from active
> or inactive to clean and protects "vclean(); v
On Wed, Nov 20, 2013 at 07:01:15PM -0500, Ken Hornstein wrote:
> #define TAILQ_PREV(elm, headname, field)\
> (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
There's another wrinkle, however, which is that this code (TAILQ_PREV)
also violates th
On Thu, Nov 21, 2013 at 01:16:44AM +0100, Rhialto wrote:
> Ever since I grokked the elegance of Lists in AmigaOS, I've always
> wondered why other list implementations do it differently.
One reason is that with Amiga lists is that the list node structure
needs to be at the beginning of the objec
On Thu, Nov 21, 2013 at 08:55:44AM -0500, Ken Hornstein wrote:
> >On Wed, Nov 20, 2013 at 07:01:15PM -0500, Ken Hornstein wrote:
> > > #define TAILQ_PREV(elm, headname, field) \
> > > (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
> >
> >There's
On Thu, Nov 21, 2013 at 11:02:24PM -0500, Ken Hornstein wrote:
> >Modulo some administrative details, it's just "no object in memory may
> >be accessed using more than one type".
>
> Ok ... I _think_ I see it. But doesn't that mean that like 90% of the casts
> used by C programmers are total
On Sat, Nov 23, 2013 at 12:59:04AM -0500, Mouse wrote:
> > Note that the bog-standard (struct sockaddr *) cast that one needs
> > and conventionally uses to call bind(2), connect(2), accept(2), and
> > similar is, strictly speaking, illegal.
>
> I don't think so. The aliasing rules don't say
601 - 700 of 951 matches
Mail list logo
