On 19 Jun, Andrey Alekseyev wrote:
Hello,
I've been trying lately to develop a solution for the problem with
open() that manifests itself in ESTALE error in the following situation:
1. NFS server: echo file01
2. NFS client: cat file01
3. NFS server: echo file02 mv file02
Terry,
Thanks much for you comments, but see below.
The real problem here is that you know you did an operation
on the file which would break the name/nfsnode relationship,
but did not flush the cached name and nfsnode data.
nfs_request() actually calls cache_purge() on ESTALE, and vn_open()
Don,
I can't get very enthusiastic about changing the file system independent
code to fix a deficiency in the NFS implementation.
You're right. But it appears to be hard and inefficient to fix NFS for this
(I tried, though). It will certainly require to pass names below VFS.
On the other hand,
On 20 Jun, Andrey Alekseyev wrote:
In the normal situation, namecache entry+vnode+nfsnode+file handle may
stay cached for a really long time (until re-used? deleted or renamed
on the *client*). Expiring file handles (a new mechanism?) means much the
same to me as simply obtaining a new name
Andrey Alekseyev wrote:
Terry,
Thanks much for you comments, but see below.
The real problem here is that you know you did an operation
on the file which would break the name/nfsnode relationship,
but did not flush the cached name and nfsnode data.
nfs_request() actually calls
Don Lewis wrote:
+again:
error = vn_open(nd, flags, cmode);
if (error) {
+ /*
+ * if the underlying filesystem returns ESTALE
+ * we must have used a cached file handle.
+ */
+ if (error == ESTALE stale++
On Thu, Jun 19, 2003 at 12:11:26PM -0700, Tim Kientzle wrote:
That would seem to be the hard part. I presume you've
looked at SUSE's YAST, Debian's APT, and other such tools?
*nods* - nice basis, but not... well... you know.
What I have now works as follows:
* Start reading the package,
On Thu, Jun 19, 2003 at 02:26:13PM -0400, The Anarcat wrote:
It's right now to the point I wouldn't consider writing more code for
libh, but I'd reuse the ideas in a smaller, plugin-based, swig-foobar
rewrite.
I went back and re-read the notes on the website about libh's design
yesterday,
On Thu, Jun 19, 2003 at 09:50:14PM -0700, Terry Lambert wrote:
Like the English policeman, they were alarmed
when they thought about it, but about all they could contractually
do was say Stop! Or we'll ask you to 'Stop!' again!.
Sorry to go off on a tangent (follow-up set to -chat), but as
Tkachenko, Artem N [EMAIL PROTECTED] 44 lines of wisdom included:
What I am trying to accomplish is to set up Node A and Node B (and not Node
C) to have Node A think that it is directly connected to LAN2 with an IP
Address 10.77.1.2
So if Node A needs to send a packet to Node C, some program
Hi,
Josef Grosch wrote on Thu, Jun 19, 2003 at 09:19:46PM -0500:
On Thu, Jun 19, 2003 at 10:08:34PM -0400, Jim Durham wrote:
After reading that really great article last night on opensource.org
about the SCO thing , I tried to bring it up tonight and it looks
like both their nameservers
What happend to this host? I cannot ping it more than 10 hours.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
Harti,
Just try one of the other mirrors.
cvsup[1-7]?.de.freebsd.org
cvsup[1-9]?.freebsd.org
/Oli
On Fri, 20 Jun 2003, Harti Brandt wrote:
What happend to this host? I cannot ping it more than 10 hours.
harti
--
harti brandt,
[ this is really not hackers@ material ]
On Fri, Jun 20, 2003 at 02:24:17PM +0200, Harti Brandt wrote:
What happend to this host? I cannot ping it more than 10 hours.
although verio is advertising 198.104.0.0/16, they are blackholing it.
7 xe-0-2-0.r20.snjsca04.us.bb.verio.net
TL Quite cool!
TL NB: If you are strict NSS, you might be able to use the
TL nss_ldap from FreeBSD without modification.
TL I think this is ideal, so long as you can have multiple
TL concurrent requests (e.g. there is at least a 64bit tag that
TL gets given with the request and returned with the
On Fri, Jun 20, 2003 at 11:12:00AM +0100, Paul Robinson wrote:
On Thu, Jun 19, 2003 at 09:50:14PM -0700, Terry Lambert wrote:
Like the English policeman, they were alarmed
when they thought about it, but about all they could contractually
do was say Stop! Or we'll ask you to 'Stop!'
Paul Robinson wrote:
... if I want to install package A which requires B and C, B
requires D and E, and D requires F, your installer would go Start A - I
need B - Start B - I need D - Start D - I need F - Install F - Install
D - I need E - Install E - Install B - Install C
In the chain above,
In linux, there are two functions specifically for removable media drivers (like
floppy cdrom), namely, check_media_change and revalidate.
Is there a corresponding set of functions in FreeBSD? How do you tell if a diskette
has changed?
___
[EMAIL
Don,
One case where there is a difference between timing out old file handles
and just invalidating them on ESTALE:
Frankly, I just didn't find any mechanism in the STABLE kernel that
does timing out for file handles. Do you mean, it would be nice to have
it or are you trying to point it out
Eh, but the generation number for file1 should have been changed! This will
I'm sorry, the generation number is not changed in your scenario. Thus,
I believe if the sequence of actions on the server is
mv file1 tmpfile
mv file2 file1
mv tmpfile file1
like you described, it's safe to continue
Terry,
The place to correct this is probably the underlying FS. I'd
argue that getting ESTALE is a poke with a sharp stick that
makes this more likely to happen. ;^).
Initially I was going to fix the underlying FS (that is, the NFS code).
But it's extremely hard to do nice, because I need
I am unclear why rc.sendmail works the way it works. For instance, in my
rc.conf I have the following:
sendmail_enable=YES
sendmail_flags=-L sm-mta -bd -q30m
sendmail_outbound_enable=YES
sendmail_outbound_flags=-L sm-queue -q30m
Note: I am not running the localhost submission agent and its
On 20 Jun, Andrey Alekseyev wrote:
Don,
One case where there is a difference between timing out old file handles
and just invalidating them on ESTALE:
Frankly, I just didn't find any mechanism in the STABLE kernel that
does timing out for file handles. Do you mean, it would be nice to
On 20 Jun, Andrey Alekseyev wrote:
Eh, but the generation number for file1 should have been changed! This will
I'm sorry, the generation number is not changed in your scenario. Thus,
I believe if the sequence of actions on the server is
mv file1 tmpfile
mv file2 file1
mv tmpfile file1
On Wed, 18 Jun 2003, Dmitry Sivachenko wrote:
Is there any reason why struct ipc_perm is not protected by #ifdef _KERNEL
in ipc.h? Is it supposed to be used from userland?
It's needed by ipcs.
Ah, I see. It is visible via struct msqid_ds.
I developed a patch which requires
Don,
old vnode and its associated file handle. If the file on the server was
renamed and not deleted, the server won't return ESTALE for the handle
I'm all confused and messed up :) Actually, a rename on the server is not
the same as sillyrename on the client. If you rename a file on the
Hi ,
I was making a new locale for Armenian and it seams that found a bug in
substitute routines.
The problem is, that the colldef with substitution seams to have a buggy
behaviour.
When a locale has a LC_COLLATE defined with a substitution like German 'ß'
which is
substituted with 'ss', then a
- Terry Lambert's Original Message -
Specifically, see the underline part of:
+ if (error == ESTALE stale++ == 0)
---
...he exits it after retrying it fails, and falls into the
standard ESTALE return case.
If this
I'm writing a remote block device on FreeBSD 4.6.2
As far as the network part is rather difficult, I don't want to include it
in the kernel module. So I started coding my module with this overall
structure in mind :
- a program reads the block device.
- the module receives read and write uio
Hi,
I am trying to set up a remote access server. I have the fallowing picture:
Node1 --Internet--Node2---LAN using IP
Node1:
Win2K
VPN connection using PPTP
IP (public) = 129.197.23.232
Node2:
FreeBSD
Remote access server (need to set up)
IP (public) = 129.197.244.6
Kris Kennaway wrote:
On Fri, Jun 20, 2003 at 11:12:00AM +0100, Paul Robinson wrote:
On Thu, Jun 19, 2003 at 09:50:14PM -0700, Terry Lambert wrote:
Like the English policeman, they were alarmed
when they thought about it, but about all they could contractually
do was say Stop! Or
31 matches
Mail list logo
