On Tue, Dec 13, 2011 at 12:20:16AM -0500, Mouse wrote:
> > Possibilities other than zero or one are not useful in manual pages,
>
> Then we can throw away fsck, because there is always _some_ chance the
> filesystem will be irreparable. Memory, CPUs, disks, and the
> transports between them do fa
Hello
FUSE has no way to send the calling process secondary groups to the
filesystem. A filesystem that wants this operation currently has to
open a /proc file, read and parse the string represnetation of the
groups, and close the file.
This is not very good performance-wise, as the filesystem
On Tue, Dec 13, 2011 at 02:19:30PM +, Emmanuel Dreyfus wrote:
> A third way was suggested on the fuse-devel mailing list: adding a
> system call to retreive a process' secondary groups. The prototype
> would be moddled on getgroups(2):
>
> int getgroups2(int gidsetlen, gid_t *gidset,
Currently we have both EOPNOTSUPP ("Operation not supported") and
ENOTSUP ("Not supported") errnos. EOPNOTSUPP is historical; ENOTSUP
was randomly added by POSIX relatively recently.
And lately I've noticed a tendency to conflate them, which isn't
healthy.
It is too late to do #define ENOTSUP EOP
I did it again. gmail is trying to teach an old dog a new trick
-- Forwarded message --
From: Donald Allen
Date: Tue, Dec 13, 2011 at 10:04 AM
Subject: Re: Lost file-system story
To: David Holland
On Tue, Dec 13, 2011 at 1:27 AM, David Holland wrote:
> On Mon, Dec 12, 20
> > Linux ext2 is not a Unix-based filesystem and Linux itself is not a
> > Unix-based kernel.
>
> It's about as Unix-based as NetBSD is. Unless you mean something
> strange by "Unix-based" - what _do_ you mean by it?
I'm guessing that the point is that ext2 is a scaled-up
re-implementation of m
In article <20111213141930.ge15...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
>Hello
>
>FUSE has no way to send the calling process secondary groups to the
>filesystem. A filesystem that wants this operation currently has to
>open a /proc file, read and parse the string represnetation of the
At 14:55 Uhr -0400 22.7.2011, David Riley wrote:
>I filed this report a while back. Someone else has tested my fix on
>non-PPC systems (x86, x86_64) and reported that it seems to work as well.
>I'm attaching the patch against -current here;
[appended to PR kern/44412]
>could someone give it a
>l
On Tue, Dec 13, 2011 at 01:38:57PM +0100, Joerg Sonnenberger wrote:
>
> fsck is supposed to handle *all* corruptions to the file system that can
> occur as part of normal file system operation in the kernel. It is doing
> best effort for others. It's a bug if it doesn't do the former and a
> poten
So, I told some people that I'd run benchmarks to qualify the TLS
(Thread Local Storage) vs no-TLS overhead, both for Xen and native
setups, i386 and amd64.
For results, jump directly at the bottom of this mail.
=== Context ===
To compare GENERIC and XEN3 kernels, the GENERIC kernel was alway
At Wed, 14 Dec 2011 09:06:23 +1030, Brett Lymn
wrote:
Subject: Re: Lost file-system story
>
> On Tue, Dec 13, 2011 at 01:38:57PM +0100, Joerg Sonnenberger wrote:
> >
> > fsck is supposed to handle *all* corruptions to the file system that can
> > occur as part of normal file system operation in
On Tue, Dec 13, 2011 at 4:09 PM, Greg A. Woods wrote:
> At Wed, 14 Dec 2011 09:06:23 +1030, Brett Lymn
> wrote:
> Subject: Re: Lost file-system story
>>
>> On Tue, Dec 13, 2011 at 01:38:57PM +0100, Joerg Sonnenberger wrote:
>> >
>> > fsck is supposed to handle *all* corruptions to the file syste
You should be aware when rerunning benchmarks MP that unless we have
had a radical improvement since June, build.sh will run faster with 14 CPUs
hot than with 24.
Thor
At Mon, 12 Dec 2011 18:49:31 -0500 (EST), "Matt W. Benjamin"
wrote:
Subject: Re: Lost file-system story
>
> Why would sync not be effective under MNT_ASYNC? Use of sync is not
> required to lead to consistency expect with respect to an arbitrary
> point in time, but I don't think anyone ever be
Christos Zoulas wrote:
> Don't you need a getuid2(pid_t pid)?
uid, gid and pid are passed inthe FUSE header, so we aready have them.
> Why don't you add separate fuse messages to send and retrieve this
> information? Then the kernel can notify if these have changed...
That adds a lot of state
On Wed, Dec 14, 2011 at 06:05:53AM +0100, Emmanuel Dreyfus wrote:
>
> At this point, I think I will fetch secondary groups through sysctl,
> this seems to be the point of least resistance.
You are not worried about security issues resulting from the fact
that time will pass, and the process may d
Thor Lancelot Simon wrote:
> > At this point, I think I will fetch secondary groups through sysctl,
> > this seems to be the point of least resistance.
>
> You are not worried about security issues resulting from the fact
> that time will pass, and the process may do other operations which
> mod
On Wed, 14 Dec 2011 07:04:06 +0100
m...@netbsd.org (Emmanuel Dreyfus) wrote:
> - a fixed lentgh header is highly desirable for performance
> optimization. For instance glusterfs fetches the header and the data
> using readv(2) with an iovec that has two slots. That way it gets write
> date aligned
hi,
> At this point, I think I will fetch secondary groups through sysctl,
> this seems to be the point of least resistance.
do you mean to implement fuse_getgroups for NetBSD with the sysctl?
if you are adding a #ifdef NetBSD block to the fuse, can't it use
a NetBSD-specific sidechannel to get t
wo...@planix.ca ("Greg A. Woods") writes:
>easy, if not even easier, to do a "mount -u -r"
Does this work again?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
mm_li...@pulsar-zone.net (Matthew Mondor) writes:
>What does NFS do in this case? I seem to remember that it also imposes
>a sane size limit, possibly even below NGROUPS_MAX, is it really the
>case? If so, would this also be acceptable?
NFS (or rather the underlying SunRPC) passes an array of 1
21 matches
Mail list logo
