On Sat, May 07, 2011 at 09:28:23PM +0200, Emmanuel Dreyfus wrote:
On NetBSD-5.1, when an FFS filesystem has extended attributes, any call
to statfs(2) will never return from the kernel. ps -axl shows the
process is sleeping at tstile.
Is it a known problem, is there already a PR for it?
On Sun, May 08, 2011 at 01:36:53PM -0400, der Mouse wrote:
That could be part of my confusion, then. Speaking strictly from a
personal-experience historical perspective, FFS was the Berkeley Fast
File System, added no later than 4.2 (can't recall whether it was in
4.1c) and UFS was Sun's
On Sun, May 08, 2011 at 10:45:15PM +0200, Martin Husemann wrote:
For example this is from an i386 5.1 machine:
[snip]
This is a FFSv1 file system (called UFS1 in the dumpfs output), but the
superblock is in FFSv2 format.
Compare to this:
[snip]
Here we have a FFSv2 file
On Sun, May 15, 2011 at 06:13:48PM +0200, Joerg Sonnenberger wrote:
How about adding fcntl(F_GETPEER) returning pid_t, then you can do
kill(fcntl(fd, F_GETPEER))?
There's still a race -- if your process sleeps between the fcntl
and the kill system calls, you can kill the wrong
On Sat, Jun 04, 2011 at 01:09:19PM -0500, David Young wrote:
Is there a good reason that we are not using stdbool.h and stdint.h
in the kernel, instead of sys/stdint.h and sys/types.h? It seems
to me that we could cut simplify by using the same headers for the same
definitions everywhere.
On Sat, Jun 04, 2011 at 02:27:59PM -0700, John Nemeth wrote:
} Is there a good reason that we are not using stdbool.h and stdint.h
} in the kernel, instead of sys/stdint.h and sys/types.h? It seems
} to me that we could cut simplify by using the same headers for the same
}
On Sat, Jun 04, 2011 at 07:03:34PM -0700, John Nemeth wrote:
}The files in src/sys/sys get installed into /usr/include/sys .
}
} Yes, I'm aware of that. Your point being?
Then what purpose would src/sys/include serve?
To hold header files? I think the point you're missing
On Mon, Jun 20, 2011 at 12:32:25PM -0700, Brian Buhrow wrote:
I don't think this is a bug as it behaves this way on NetBS-3.x, 4.x and
5.x. Can anyone provide clue?
Check the group memberships of the processes?
--
David A. Holland
dholl...@netbsd.org
On Thu, Jun 16, 2011 at 07:49:43PM +0200, Manuel Bouyer wrote:
I'm not in favor of LOCKDEBUG by default, for reasons already stated here.
Also, could LOCKDEBUG have ABI issues with modules ?
I've only ever used LOCKDEBUG with non-MODULAR kernels ...
The whole reason LOCKDEBUG is
We got a new NFS server at work over the weekend, and it's been a bit
flaky and causing my machines to hang left and right. In the course of
poking about with ddb and crash I've found no less than three
problems:
(1) The syncer holds syncer_mutex while calling VOP_FSYNC. If
VOP_FSYNC goes off to
On Wed, Jun 22, 2011 at 10:26:47PM +0200, Manuel Bouyer wrote:
Any idea on how to properly fix this ?
a workaround could be to use yield() in uvm_loan.c because it would not
require a clock tick to wake up.
I'm not sure if it's possible to drop the socket lock before unloaning the
On Fri, Jun 24, 2011 at 01:43:34AM +0200, Johnny Billquist wrote:
In other words, Erik is right, at least if we're talking historically.
Of course, at least there it's documented. (I took a quick glance
at the code, too -- it did appear to check for erroneous parameters,
though I think it
On Fri, Jun 24, 2011 at 11:33:51AM -0400, der Mouse wrote:
Oh, I was talking about current NetBSD where block devices are a
second class citizen, soon to be abolished if someone finds enough
round tuits.
Yes, so it keeps being said. It would truly be a pity to see that
happen.
On Fri, Jun 24, 2011 at 12:11:22PM +0200, Manuel Bouyer wrote:
I've been thinking that the nfs client problems I've been seeing,
which seem to be callout-related, are maybe connected, as could be the
odd problem mrg has been having with raidframe.
Do we have a debug hook or other
On Fri, Jun 24, 2011 at 06:37:09PM +0100, David Laight wrote:
Do we have a debug hook or other method that will raise a panic if
callouts stop getting processed?
unfortunably, no (AFAIK).
without looking at the code (today) I'm wondering if it would be
feasible to have
On Sat, Jun 25, 2011 at 09:29:57PM +0700, Robert Elz wrote:
| At least for NetBSD, that's never been true. The most glaring
| problem is that there's no protection against causing the same
| underlying disk blocks to be multiply cached by accessing the
| buffer cache with a different
On Sat, Jun 25, 2011 at 08:57:30PM +0200, Johnny Billquist wrote:
I might be confused here. I thought that if you accessed the block
device, you were restricted to blocks. So you can in fact not seek
to an arbitrary byte, nor read an arbitrary length, like for a
normal file, but instead
On Sun, Jun 26, 2011 at 04:48:22AM +0200, Emmanuel Dreyfus wrote:
I implemented extattr_list_file for UFS1. The thing works fine, but I
notice the data expected by lsextattr(8) is not in the same shape as
described in NetBSD documentation and in FUSE and Linux.
I'll throw a spanner in the
On Wed, Jun 29, 2011 at 09:31:33AM +, Emmanuel Dreyfus wrote:
The conversion is easy to do, but the right place to do it is
tricky. VOP_LISTEXTATTR() writes its output to the userland
buffer, therefore if I convert in src/sys/ufs/ufs/ufs_extattr.c, I
have to copyin/convert/copyout,
On Fri, Jul 01, 2011 at 01:10:06AM +, YAMAMOTO Takashi wrote:
hi,
That said, even if you don't like the suggestion of using struct
dirent, ISTM that the preferred user API for listing extended
attributes should be something more like opendir/readdir.
do you know any
On Fri, Jul 15, 2011 at 10:43:31PM +, David Holland wrote:
I will commit it later after an anita run if I don't find any more
problems.
I did find one more problem... hopefully no more than that.
Note that when pounding on rename I am occasionally seeing:
panic
On Sat, Jul 16, 2011 at 08:04:15AM +, David Holland wrote:
This seems to be connected to rmdir, not rename. The panic has (so
far) always occurred in a process doing only rmdirs and no renames.
I've spotted two problems in ufs_rmdir but neither of them could be
causing this; as far
On Mon, Jul 18, 2011 at 09:37:33AM -0400, Thor Lancelot Simon wrote:
On Mon, Jul 18, 2011 at 08:00:18AM +, David Holland wrote:
Other fses with their own rename implementations whose locking is
clearly wrong include tmpfs, msdosfs, udf, and nilfs
On Mon, Jul 18, 2011 at 10:03:06PM +0200, Adam Hoka wrote:
Other fses with their own rename implementations whose locking is
clearly wrong include tmpfs, msdosfs, udf, and nilfs.
As opposed to ffs? What's your point?
I think he meant that it's most likely to be used in a
On Tue, Jul 19, 2011 at 08:50:35PM -0500, Eric Haszlakiewicz wrote:
As opposed to ffs? What's your point?
I think he meant that it's most likely to be used in a production
environment.
And ffs isn't? I still don't get the point.
Didn't you just say that ffs is already
On Wed, Jul 27, 2011 at 05:58:53PM +, Eduardo Horvath wrote:
OTOH, how many times have you seen code like this:
foo(vmem_t *v) {
void *p;
vmem_alloc(v, 52, 0, (vmem_addr_t *)p);
which has implementation defined functionality.
Code like that usually
On Fri, Jul 29, 2011 at 11:17:46AM -0400, Mouse wrote:
If linux_link(2) seems unreasonable, it could be lazy_link(2),
weak_link(2), braindead_link(2) or whatever.
You'll also need to update every filesystem to allow this and update
all the various fsck programs to allow filesystems to
On Sun, Jul 31, 2011 at 07:49:20PM +0200, Emmanuel Dreyfus wrote:
Quick summary for the impatient: NetBSD link(2) first resolves symlinks
before doing the actual link to the target. As a result, NetBSD link(2)
fails on symlinks to directories or to non existent targets.
On the other
On Mon, Aug 01, 2011 at 04:05:32AM +0200, Emmanuel Dreyfus wrote:
You still haven't explained what glusterfs is doing that's so evil or
why it can't be fixed by having it copy the symlink when that's the
case in question.
glusterfs uses the native filesystem as its storage backend.
On Mon, Aug 01, 2011 at 09:31:11PM +0100, David Laight wrote:
+ if (flags FOLLOW)
+ namei_simple_flags = NSM_FOLLOW_TRYEMULROOT;
+ else
+ namei_simple_flags = NSM_NOFOLLOW_TRYEMULROOT;
+
+ error = namei_simple_user(path, namei_simple_flags, vp);
Not
On Mon, Aug 01, 2011 at 09:00:36PM +, David Holland wrote:
Not withstanding dh's comment, why not pass in all the namei flags.
+ error = namei_simple_user(path, flags, vp);
Because I gimmicked up the flags for namei_simple specifically to
disallow that sort of thing
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: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
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
So I just had an idea: since cleaning /tmp on a live system is very
dangerous unless done so (and even then somewhat dangerous), plus
there are other possible uses for automatically disappearing files:
How hard would it be to add a mount option for tmpfs to automatically
drop files after a given
On Sun, Aug 07, 2011 at 09:25:59AM +0300, Jukka Ruohonen wrote:
On Sun, Aug 07, 2011 at 03:10:29AM +, David Holland wrote:
So I just had an idea: since cleaning /tmp on a live system is very
dangerous unless done so (and even then somewhat dangerous), plus
there are other possible
On Sun, Aug 07, 2011 at 09:52:11AM +0200, Reinoud Zandijk wrote:
i've implemented the SEEK_HOLE / SEEK_DATA additions to lseek() as
introduced by Solaris for ZFS.
What does this operation have to do with seeking? And why involve the
seek pointer, especially at a time when new calls are being
On Sun, Aug 07, 2011 at 10:40:00AM +0300, Jukka Ruohonen wrote:
Sounds like a job for the userland and cron(8).
uh no.
See: since cleaning /tmp on a live system is very dangerous
So care to elaborate what is dangerous about it?
It's a security FAQ. If you do rm -rf (or
On Sun, Aug 07, 2011 at 06:29:01PM +0200, Marc Balmer wrote:
And what is auto-erasing files good for in the first place? I don't get
the point, for me it's calling for trouble.
Traditionally, it's so /tmp doesn't grow without bound, which once
upon a time was a problem with small root
On Sun, Aug 07, 2011 at 12:11:49PM -0400, Mouse wrote:
It's a security FAQ. If you do rm -rf (or nearly any of the other
obvious/easy alternatives) in a world-writable directory, a hostile
user can interact with it to erase any file on the system.
I believe that this is partially
On Sun, Aug 07, 2011 at 06:59:32PM +0200, Emmanuel Dreyfus wrote:
But that is uber-stupid ;) Something tries to access a file, which is
perfectly there, and instead of returning the data, we toss the data
away and return ENOENT... ???
If I understood correctly the idea, you do this
On Sun, Aug 07, 2011 at 06:52:03PM +0200, Reinoud Zandijk wrote:
i've implemented the SEEK_HOLE / SEEK_DATA additions to lseek() as
introduced by Solaris for ZFS.
What does this operation have to do with seeking? And why involve the
seek pointer, especially at a time when new
On Sun, Aug 07, 2011 at 01:54:01PM -0500, Eric Haszlakiewicz wrote:
However, since there's no way to make rmdir(2) use NOFOLLOW, we
have to either leave directory structure in place or risk removing an
attacker's choice of empty directories.
?
valkyrie% ls -l
total 4
On Sun, Aug 07, 2011 at 02:48:14PM -0400, Mouse wrote:
lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar
valkyrie% rmdir baz
rmdir: baz: Not a directory
! Hm, I see that too.
I wonder where I got the idea it followed symlinks.
Probably because in sys_rmdir:
On Sun, Aug 07, 2011 at 10:03:34PM +0200, Reinoud Zandijk wrote:
i've implemented the SEEK_HOLE / SEEK_DATA additions to lseek() as
introduced by Solaris for ZFS.
One `seeks' the next hole of data block in the file from a given
pos? Sounds logical to me.
But you don't.
On Sun, Aug 07, 2011 at 08:39:51PM -0500, Eric Haszlakiewicz wrote:
Even your example code does this: it seeks repeatedly, teleporting the
seek pointer all over the place for no reason, then does a bunch of
reads.
So yes, it changes the file pointer too but thats a side-effect
On Tue, Aug 09, 2011 at 07:13:44PM +0200, Emmanuel Dreyfus wrote:
Yes, a TTL attribute on an inode: once it expires, the filesystem tosses
the file on next access attempt.
If it were done at the next directory listing attempt, it would make
more sense (and the removed file should
On Fri, Aug 05, 2011 at 05:48:33AM +0200, Emmanuel Dreyfus wrote:
i tend to think it's better to just kill the freebsd flavor of syscalls.
I think the API is ill-designed too. Even the function names are at odds
with usual Unix practice.
What we can do is to depreciate the FreeBSD
On Tue, Aug 23, 2011 at 03:11:27AM -0400, Mouse wrote:
[...] gcc errors due to comparison of signed and unsigned values.
It is best to fix the errors.
In my experience, that warning produces so many more false positives
than useful warnings that I normally shut it off entirely.
and
On Mon, Aug 29, 2011 at 03:49:09AM +0200, Emmanuel Dreyfus wrote:
because those requests have ended up in your file server which is
waiting for page daemon and thus deadlock? just a wild guess, though.
So the right fix would be to have a uvm.user_paging count for pages from
non
On Fri, Sep 09, 2011 at 08:38:59AM +0200, Rhialto wrote:
There's also a possible issue with direct selection data transfer
versus INCR data transfer, but in xterm's case that is unlikely to be
what's behind your problem. It's hard to be sure; you outline
conditions under which you see
On Sun, Sep 04, 2011 at 12:10:17PM +0200, Manuel Bouyer wrote:
Look at the cvs history, if you do that the com ports tend to get
reversed.
There is no way of fixing the order of the com ports when acpi is used.
Now the big question is: What is more important? Having _no_ com
On Thu, Sep 22, 2011 at 08:24:48AM -0700, Paul Goyette wrote:
It would appear that wapbl is only relevant for ffs file systems
(and in particular, only for ffs filesystems with a V2 superblock
format).
Yet the current modularization of wapbl is not dependant on the
ffs module.
On Mon, Sep 26, 2011 at 09:17:43PM +0300, Jukka Ruohonen wrote:
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going
On Thu, Sep 29, 2011 at 11:42:07AM +1000, matthew green wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going to
see a 65535 MHz processor any time soon. But sure,
On Wed, Sep 28, 2011 at 10:16:29PM -0400, Mouse wrote:
If that periodically-threatened pdp10 port (or some other off-size
port) ever appears, it's not likely to care about the size that
appears in some other environment (unlike for on-disk structures) and
using an explicit size will if
On Thu, Sep 29, 2011 at 09:26:12AM -0500, paul_kon...@dell.com wrote:
The cache and mmu are probably harder than the cpu :-)
I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging
on that score. And I have no idea what it had for an MMU. The only
On Mon, Oct 03, 2011 at 12:40:46AM -0700, Erik Fair wrote:
We ought to try and come up with a notification abstraction model
that works reasonably well for each use case, and preferably one
which permits automated userland software response to various
common events.
Trying to enumerate
On Fri, Oct 14, 2011 at 03:23:05PM +0200, Nicolas Joly wrote:
/local/src/NetBSD/src/sys/dev/ic/bwivar.h(773): void function
bwi_rf_lo_update cannot return value [213]
/local/src/NetBSD/src/sys/dev/pci/if_sip.c(1113): void function
sipcom_attach cannot return value [213]
So, a few months back we got a new improved quota format for FFS.
Unfortunately, one of the side effects of this was to sprinkle
specific knowledge of the new format through all the userlevel quota
tools and quota support logic. To be fair, this was alongside the
existing specific knowledge of the
On Wed, Oct 19, 2011 at 09:22:02PM +0200, Manuel Bouyer wrote:
So, a few months back we got a new improved quota format for FFS.
Unfortunately, one of the side effects of this was to sprinkle
specific knowledge of the new format through all the userlevel quota
tools and quota support
On Wed, Oct 19, 2011 at 10:01:33PM +0100, David Laight wrote:
some dtrace ioctls, including DTRACEIOC_AGGSNAP, are defined as
the following.
#define DTRACEIOC_AGGSNAP _IOW('x',7,dtrace_bufdesc_t *)
and libdtrace has diffs like the following.
#if
On Thu, Oct 20, 2011 at 06:43:47AM +0200, Emmanuel Dreyfus wrote:
It seems to me that quotas are fundamentally a special-purpose
key/value store; that is, you look up quota information for a
particular thing (the key) and get back the quota settings and current
usage information (the
On Thu, Oct 20, 2011 at 11:57:04AM +0200, Ignatios Souvatzis wrote:
support to other filesystems (tempfs, perhaps v7fs) or even add other
filesystems that have or may have their own native quota handling
(zfs, Hammer, you name it).
zfs - does it really have quota?
I don't know...
On Thu, Oct 20, 2011 at 05:23:14PM +0200, Manuel Bouyer wrote:
That's way more complicated than necessary. Think of it as like
VOP_READDIR - you get passed a position, you send back some number of
items, and update the position.
Depending on how the data are stored on disk, the
On Thu, Oct 20, 2011 at 06:00:28PM +0200, Manuel Bouyer wrote:
It's certainly less trouble to send back to userland the whole set of
data - especially if what userland wants is the whole set of data
(I can't see what a partial read of quota would be usefull for).
No, no it
On Wed, Oct 19, 2011 at 06:09:27PM +, David Holland wrote:
So, a few months back we got a new improved quota format for FFS.
[...]
All right, I give up. Apparently the commandment Thou Shalt Not
Question the use of the Holy Proplib is more important to the
community than sanity
On Fri, Oct 21, 2011 at 08:25:44AM +, David Holland wrote:
On Wed, Oct 19, 2011 at 06:09:27PM +, David Holland wrote:
So, a few months back we got a new improved quota format for FFS.
[...]
All right, I give up.
ok, I have been asked by Important People(TM) to resurrect
On Sun, Oct 30, 2011 at 12:43:57PM -0500, David Young wrote:
On Wed, Oct 19, 2011 at 06:09:27PM +, David Holland wrote:
So, a few months back we got a new improved quota format for FFS.
[...]
All right, I give up.
ok, I have been asked by Important People(TM
On Mon, Oct 31, 2011 at 11:49:29AM -0400, Matthew Mondor wrote:
Unless someone suggests a good word for limited thing, maybe the best
option is to invent a term of art and *define* it to mean what you
want, after the manner of Humpty Dumpty. To that end I suggest
quotar or quoton.
On Wed, Nov 09, 2011 at 09:52:13AM -0600, Eric Haszlakiewicz wrote:
I don't think it guarantees it by itself. That is, if you want to access
the data on a different CPU, you either need to take the mutex (and the
read barrier in mutex_enter) or issue an explicit barrier.
I'm a bit
On Wed, Nov 09, 2011 at 02:40:19AM -0500, Mouse wrote:
I found mutex(9), condvar(9), and the like. But it is not clear to me
what I need to do to be MP-ready. Do I need to use the stuff from
mb(9), or membar_ops(3), or what? It's not clear from the manpages
whether, for example,
On Thu, Nov 10, 2011 at 06:08:06PM +, David Laight wrote:
It is unusual to try to do SMP programming where the cpu's don't
to cache snooping/coherency,
Well, now it is. It took a long time to persuade the hardware guys
that manual cache coherence isn't workable.
--
David A. Holland
On Sun, Oct 30, 2011 at 01:28:18PM -0400, James K. Lowden wrote:
- We still need suggstions for better terminology than quota classes
and quota types.
Our last words on that subject were on 20 October:
right...
Two pairs that strike me as more mnemonic:
id,
On Sat, Oct 29, 2011 at 05:14:30PM +, David Holland wrote:
The new discovery that struct ufs_quota_entry is meant to be
fs-independent changes the complexion of things quite a bit.
ok, so my poor choice of wording and/or bikeshedding burnout has
caused this thread to run down, except
On Tue, Sep 27, 2011 at 03:48:29PM +0700, Robert Elz wrote:
| But it is better long term to move forward and allow for longer
| names.
Why?
I was recently talking to some people who'd been working with some
(physicists, I think) doing data-intensive simulation of some kind,
and that
On Sun, Nov 13, 2011 at 10:36:55PM +0100, Manuel Bouyer wrote:
On Sat, Oct 29, 2011 at 05:14:30PM +, David Holland wrote:
[...]
3. Abolish the proplib-based transport encoding. Since it turns out
that the use of proplib for quotactl(2) is only to encode struct
On Mon, Nov 14, 2011 at 04:03:09AM -0500, Matthew Mondor wrote:
I was recently talking to some people who'd been working with some
(physicists, I think) doing data-intensive simulation of some kind,
and that reminded me: for various reasons, many people who are doing
serious data
On Mon, Nov 14, 2011 at 05:39:02PM +, David Laight wrote:
pkgsrc has grown to the point where the following happens:
valkyrie% pwd
/usr/pkgsrc
valkyrie% grep foo */*/Makefile
/usr/bin/grep: Argument list too long.
Exit 1
Use: grep -r --include Makefile
On Tue, Nov 15, 2011 at 11:54:12AM +0100, Manuel Bouyer wrote:
3. There's already been some discussion of the compat issues in this
thread. Basically it boils down to: if you send a program material
that it's not expecting to receive, it won't be able to cope with it
and will
On Thu, Nov 17, 2011 at 05:10:24PM +0100, Manuel Bouyer wrote:
What am I missing?
the quotactl call has different commands, which takes different arguments.
For example, quotaon takes a string, while setquota takes a struct
describing the quotas to be set.
With the old quotactl, the
On Thu, Nov 17, 2011 at 05:29:22PM +0100, Manuel Bouyer wrote:
I still believe proplib is better. For example, you can go from a
32bit to a 64bit uid_t/gid_t without versionning (in the data structure
it's still integer/integer).
NO YOU CAN'T. Sorry for shouting, but this really annoys me.
On Thu, Nov 17, 2011 at 11:50:06AM -0600, David Young wrote:
I don't think it matters whether it is simple and straightforward to
create a language binding or not.
The advantage to using some standard format for quotas, be it
tab-delimited tables or plists, is that if you know the
On Fri, Nov 18, 2011 at 06:31:21AM +, YAMAMOTO Takashi wrote:
postgresql assumes instant lseek(SEEK_END) to get the size of
their heap files.
http://rhaas.blogspot.com/2011/11/linux-lseek-scalability.html
as fsync etc keeps the vnode lock during i/o, it might cause severe
On Wed, Nov 23, 2011 at 05:03:36PM +, Christos Zoulas wrote:
If no one argues otherwise, I would like to import chewiefs to the NetBSD
tree.
The import would have minimal impact on existing code, but would
allow for broader testing of the code and a step towards a more
embedded
On Thu, Nov 24, 2011 at 11:39:33AM +0100, Emmanuel Dreyfus wrote:
When perfused sends a lookup down to a FUSE filesystem, it may discover
that the parent node does not exist anymore. That happens on distributed
filesystems when another client deleted the directory.
Obviously perfused
On Thu, Nov 24, 2011 at 02:14:30PM +0100, Emmanuel Dreyfus wrote:
When calling lookup, the parent (directory) is supposed to be locked
to prevent exactly this sort of thing from happening. You and/or
perfuse and/or puffs ignore this at your peril, because doing so
violates atomicitiy
On Fri, Nov 25, 2011 at 08:24:20PM +0100, Emmanuel Dreyfus wrote:
What does NFS do for ESTALE cases? Whatever it is, there's probably a
way to do it via fuse, and therefore also via perfuse.
FUSE is not the problem: I need to notify the kernel through the PUFFS
API
But, if there's a
On Tue, Dec 06, 2011 at 11:10:44AM -0500, Donald Allen wrote:
My Linux experience, and this is strictly gut feel -- I have no
hard evidence to back this up -- tells me that if this had happened
on a Linux system with an async, unjournaled filesystem, the
filesystem would have survived.
On Fri, Dec 09, 2011 at 09:33:54AM +0100, Nicolas Joly wrote:
According to the online OpenGroup specification for read(2) available
at [1], read(2) on directories is implementation dependant. If
unsupported, it shall fail with EISDIR.
Not all our file systems comply, and return random
On Tue, Dec 06, 2011 at 11:58:25AM -0500, Thor Lancelot Simon wrote:
With the filesystem mounted async *nothing* pushes out most
metadata updates,
If this is really true, it's a bug and should be fixed.
--
David A. Holland
dholl...@netbsd.org
On Sun, Dec 11, 2011 at 12:35:07PM +0100, Edgar Fu? wrote:
[I tried to send this as private mail, but get
host Sparkle-4.Rodents-Montreal.ORG[216.46.5.7] refused to talk to me:
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all
On Sun, Dec 11, 2011 at 02:52:28PM -0500, Mouse wrote:
[...]
The short answer is that Mouse likes tilting at windmills. :-)
Eh. I think that is at least a little of a misstatement. I don't do
such things because I enjoy doing them. Quite the opposite.
I do them because I must.
pulling the plug was not present. Whether this is
intentional or a bug, I agree with David Holland -- it's wrong and
should be fixed.
I disagree. It is exactly why I use FFS with -o async -- to get a disk
backed storage, that doesn't waste resources, if everything fits into
memory
On Sun, Dec 11, 2011 at 06:53:26PM -0800, Greg A. Woods wrote:
You would be sure if you'd read my posts carefully. The difference is
whether the probability of an async-mounted filesystem is near zero or
near one.
I think perhaps the misunderstanding between you and everyone else is
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
On Wed, Dec 14, 2011 at 08:19:42AM +, Emmanuel Dreyfus wrote:
On Wed, Dec 14, 2011 at 01:10:19AM -0500, Matthew Mondor wrote:
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,
On Wed, Dec 14, 2011 at 10:51:20AM +, Emmanuel Dreyfus wrote:
On Wed, Dec 14, 2011 at 09:09:59AM +, YAMAMOTO Takashi wrote:
in my understanding, fuse_getgroups needs to talk with perfused,
not kernel. so i suggested creating a side channel between
fuse_getgroups and perfused.
101 - 200 of 795 matches
Mail list logo
