On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote:
Sure. But what does it actually do, such that if you have a symlink it
doesn't work to copy the symlink instead of hardlink it?
That would probably work for symlinks, since they cannot be updated.
But this would requires heavy
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote:
On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote:
Sure. But what does it actually do, such that if you have a symlink it
doesn't work to copy the symlink instead of hardlink it?
That would probably work for
On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote:
It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux
as well as FreeBSD. It might be the more portable direction to go.
Right, then everything is simple, this is just the matter of
implementing a standard
OK, I'll re-attach the drive to another machine.
I did that and the SMART status is OK.
So, anything short of re-booting the server to unlock the locked up SATA port?
I'll be losing 455 days of uptime!
On Tue, Aug 02, 2011 at 02:53:11PM +0200, Edgar Fuß wrote:
OK, I'll re-attach the drive to another machine.
I did that and the SMART status is OK.
So, anything short of re-booting the server to unlock the locked up SATA
port? I'll be losing 455 days of uptime!
I'd see if it reacts to
I am about adding linkat(2), which is defined in
The Open Group Technical Standard, 2006, Extended API Set Part 2.
However, I am not going to implement the whole Extended API Set Part 2,
at least for now. This means I am going ot have linkat(2) but not
openat(2) for instance.
That approach
hello. On a NetBSD-4.x system, I know of no way to re-enable the SATA
port short of rebooting. Once rebooted, of course, you'll be able to
rebuild your raid and start counting those uptime days again.
-Brian
On Aug 2, 2:53pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: Re: SATA:
On Tue 02 Aug 2011 at 09:05:27 +, Emmanuel Dreyfus wrote:
On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote:
It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux
as well as FreeBSD. It might be the more portable direction to go.
Right, then everything
On Tue, Aug 02, 2011 at 05:45:56PM +0200, Rhialto wrote:
Ok, then we also want openat(2), fchmodat(2) (which seems to be misnamed
and looks more like a chmodat(2)), unlinkat(2), fchownat(2) (same remark
as fchmodat), etc.
And you forgot fexecve(). I agree we want all of them, but I do not
On Tue, Aug 02, 2011 at 03:19:58PM +, Emmanuel Dreyfus wrote:
I am about adding linkat(2), which is defined in
The Open Group Technical Standard, 2006, Extended API Set Part 2.
However, I am not going to implement the whole Extended API Set Part 2,
at least for now. This means I am
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote:
Sure. But what does it actually do, such that if you have a symlink it
doesn't work to copy the symlink instead of hardlink it?
That would probably work for symlinks, since they cannot be updated.
But this would
On Tue, Aug 02, 2011 at 04:30:15PM +, David Holland wrote:
As opposed to link/unlink? I still don't see why this would be more
than a half-dozen lines of code, if that. By your previous
descriptions it already needs to stat the object to check if it's a
directory.
It is much more code,
On Tue, Aug 02, 2011 at 04:27:12PM +, David Holland wrote:
Does that mean AT_FDCW should be guarded by #ifdef _NETBSD_SOURCE
until the whole Extended API Set Part 2 is implemented?
There's a preexisting patch set for *at somewhere. It got rejected in
its original form because it did
On Tue, Aug 02, 2011 at 04:34:12PM +, Emmanuel Dreyfus wrote:
As opposed to link/unlink? I still don't see why this would be more
than a half-dozen lines of code, if that. By your previous
descriptions it already needs to stat the object to check if it's a
directory.
It is
Gentlepeople,
Some file systems use genfs_compat_getpages while others (most of them) use
genfs_getpages. I'm trying to figure out the essential differences, and why
one would pick one over the other.
Any pointers?
paul
On Tue, 2 Aug 2011 13:08:55 -0500
paul_kon...@dell.com wrote:
Gentlepeople,
Some file systems use genfs_compat_getpages while others (most of them) use
genfs_getpages. I'm trying to figure out the essential differences, and why
one would pick one over the other.
Any pointers?
On Tue, 2 Aug 2011, paul_kon...@dell.com wrote:
Gentlepeople,
Some file systems use genfs_compat_getpages while others (most of them) use
genfs_getpages. I'm trying to figure out the essential differences, and why
one would pick one over the other.
Any pointers?
genfs_vnops.c:
-Original Message-
From: Eduardo Horvath [mailto:e...@netbsd.org]
Sent: Tuesday, August 02, 2011 2:41 PM
To: Koning, Paul
Cc: tech-kern@netbsd.org
Subject: Re: genfs_getpages vs. genfs_compat_getpages
On Tue, 2 Aug 2011, paul_kon...@dell.com wrote:
Gentlepeople,
Some file systems
David Holland dholland-t...@netbsd.org wrote:
It is much more code, since it happens on the client, which sends
filesystem operations to lower layers and regain control later using
callbacks. Have a look to the sources (xlator/cluster/dht/dht-rename.c)
and you will see why it is
Emmanuel Dreyfus m...@netbsd.org wrote:
But that does not answer the original question: it is sane to
ifdef _NETBSD_SOURCE a partial implementation of linkat(), while the
full thing is not yet ready.
I can answer to myself: through config.h - float.h - whatever,
_NETBSD_SOURCE gets defined
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
Here is a reworked dynamic CPU set implementation for kernel (shared
cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface:
http://www.netbsd.org/~rmind/kcpuset_ng.diff
It supports early use while the system is cold
hi,
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
Here is a reworked dynamic CPU set implementation for kernel (shared
cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface:
http://www.netbsd.org/~rmind/kcpuset_ng.diff
It supports early use while the system is
On Tue, Aug 02, 2011 at 02:19:38PM -0500, paul_kon...@dell.com wrote:
Thanks, that helps. It makes me wonder why NTFS uses it. Not
quite such a surprise that LFS uses it...
LFS doesn't...
--
David A. Holland
dholl...@netbsd.org
23 matches
Mail list logo
