How to invalidate NFS read cache?
Hello, sporadically, I observe a strange but serious problem in our large NFS environment. NFS servers are Linux and OS X with StorNext/Xsan cluster filesystems, NFS clients Linux and FreeBSD. NFS client A changes a file, but nfs client B (running on FreeBSD) does still see the old version. On the NFS server itself, everything looks fine. Afaik the FreeBSD kernel invalidates the NFS read cache if file modification time on the server changed which should happen here but doesn't. Can I force FreeBSD (e.g. by sysctl setting) to read file buffers again unconditionally after vfs.nfs.access_cache_timeout seconds have passed? Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
undetected umass device
Hi, this is a: USB to Parallel-ATA bridge(0x0c05), Sunplus Technology Inc.(0x04fc) or in english, a nifty dongle that can be connected to ata/sata disk, but umass fails to detected it fully, and detaches it. any hints? quircks? thanks, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: undetected umass device
On Friday 08 May 2009, Danny Braniss wrote: > Hi, > this is a: > USB to Parallel-ATA bridge(0x0c05), Sunplus Technology Inc.(0x04fc) > or in english, a nifty dongle that can be connected to ata/sata disk, but > umass fails to detected it fully, and detaches it. > > any hints? quircks? > thanks, > danny > Can you get dmesg and the USB descriptors of your device? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: undetected umass device
> On Friday 08 May 2009, Danny Braniss wrote: > > Hi, > > this is a: > > USB to Parallel-ATA bridge(0x0c05), Sunplus Technology Inc.(0x04fc) > > or in english, a nifty dongle that can be connected to ata/sata disk, but > > umass fails to detected it fully, and detaches it. > > > > any hints? quircks? > > thanks, > > danny > > > > Can you get dmesg and the USB descriptors of your device? > sure, but I guess I forgot to mention, this is with 7.2-stable. port 2 addr 3: high speed, self powered, config 1, USB to Parallel-ATA bridge(0x0c05), Sunplus Technology Inc.(0x04fc), rev 10.03 umass1: on uhub7 umass1: SCSI over Bulk-Only; quirks = 0x umass1: Max Lun is 0 umass1:2:-1:-1:XPT_PATH_INQ:. umass1:2:1:-1: Attached to scbus2 umass1: Attach finished scbus2: scanning for umass1:2:1:-1 umass1:2:1:-1:XPT_PATH_INQ:. umass1:2:0:0:XPT_PATH_INQ:. umass1:2:0:0:XPT_PATH_INQ:. umass1:2:0:0:XPT_SET_TRAN_SETTINGS:. umass1:2:0:0:XPT_PATH_INQ:. umass1:2:0:0:XPT_PATH_INQ:. umass1:2:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass1: CBW 1: cmd = 6b (0x12002400), data = 36b, dir = in umass1: at uhub7 port 2 (addr 3) disconnected umass1: detached umass1: Handling BBB state 2 (BBB CBW), xfer=0xff00014c8c00, CANCELLED xpt0: Rescan succeeded umass1: detached cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
fputsock()/fgetsock() replacement
hi,
Since the comment in the kernel is:
'Note: fputsock() is deprecated, see comment for fgetsock().'
I'm looking for a replacement, on the other hand, this quote:
deprecated
Said of a program or feature that is considered obsolescent
and in the process of being phased out, usually in favour of a
specified replacement. Deprecated features can,
unfortunately, linger on for many years. This term appears
with distressing frequency in standards documents when the
committees writing the documents realise that large amounts of
extant (and presumably happily working) code depend on the
feature(s) that have passed out of favour.
See also {dusty deck}.
[{Jargon File}]
(1995-04-19)
got me wondering if I should hurry.
cheers,
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kthreads and sched_relinquish
Hi,
I'm writing a FreeBSD kernel module and I think I really misunderstand
something. My module spawns a thread, which should be running while
the module is loaded. The thread does some work and then should yield
for other threads. However, if there are no other threads waiting,
then I would like to continue to do more work. The problem is that I
am getting weird deadlocks so I wrote a simple test app to ask why
this doesn't work:
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void test_thread(void *blah) {
unsigned int i = 1; /* Limit the number of iterations */
printf("Test Thread Started\n");
while (i > 0) {
sched_relinquish(curthread);
i--;
}
printf("Test Thread Exited\n");
kthread_exit(0);
}
/* The function called at load/unload. */
static int event_handler(struct module *module, int event, void *arg) {
int e = 0; /* Error, 0 for normal return status */
switch (event) {
case MOD_LOAD:
printf("Test Module Loaded\n");
kthread_create(test_thread, NULL, NULL, 0, 0, "test");
break;
case MOD_UNLOAD:
printf("Test Module Unloaded\n");
break;
default:
e = EOPNOTSUPP; /* Error, Operation Not Supported */
}
return e;
}
/* The second argument of DECLARE_MODULE. */
static moduledata_t test_conf = {
"test_mod", /* module name */
event_handler, /* event handler */
NULL/* extra data */
};
DECLARE_MODULE(test_mod, test_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
While my thread is running the rest of the system is unresponsive. The
thread should sched_relinquish() every time round the loop, and from
my understanding that should yield to allow other threads to run, for
example the thread which executes my shell (bash). I suspect my thread
is yielding and getting instantly rescheduled. I noticed that
poll_idle() in sys/kern_poll.c does something similar to me, but they
first lower their priority. This however has not worked for me, since
my more complex module interacts with higher priority threads and ends
up deadlocking.
So I just want to ask, Why does this example code lock the system? Am
I using sched_relinquish correctly? Or should I be doing something
else? I did try using tsleep(...,1), but I don't want my thread
sleeping if there are no other threads waiting.
I would also be grateful if people could point me at other examples in
the kernel where something like this is done. I have looked in quite a
few places, but I can't see why my simple app is wrong.
thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kthreads and sched_relinquish
Your kernel thread likely has a higher priority than userspace threads. Ryan Stone ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: fdescfs brokenness
On Thu, May 07, 2009 at 08:07:46PM -0700, Tim Kientzle wrote:
> Colin Percival recently pointed out some issues
> with tar and fdescfs. Part of the problem
> here is tar; I need to rethink some of the
> traversal logic.
>
> But fdescfs is really wonky:
>
> * This is a nit, but: ls /dev/fd/18 should not
>return EBADF; it should return ENOENT, just
>like any other reference to a non-existent filename.
>(Just because a filename reflects a file descriptor
>does not mean it is a file descriptor.)
This is a traditional behaviour for fdescfs. According to man page,
open("dev/fd/N") shall be equivalent to fcntl(N, F_DUPFD, 0).
Solaris behaviour is the same.
>
> * The fairly routine recursive directory walker
>below gets hung in fdescfs. It appears that
>the two opendir() invocations active at the
>same time interfere with each other.
What you mean by "gets hung" ? In my limited testing, it works.
Opendir creates a new directory in /dir/fd by the mere fact of opening
the directory. So it walks into that dir, returning to step 1.
>
> * A similar chdir()-based version of the directory
>walker below breaks badly; you can chdir() into
>a directory under /dev/fd, but you can't chdir("..")
>to get back out of it. (This is the particular
>problem that tar is running afoul of.)
Not sure about this one. I think that fdescfs vnodes do not support
lookup on anything not being root of the fdescfs.
>
> * Running "find /dev/fd" generates bogus ENOENT errors
>because you can opendir() a directory inside of /dev/fd,
>and read the entries, but you can't access those entries
>because path searches don't work through fdescfs.
Again, this may be a consequence of the previous issue.
>
> I think the right solution here is to add a VOP_ACCESS
> handler to fdescfs that bars all access to directory
> nodes under /dev/fd. Basically, if your program has a
> directory open, that should be reflected as a directory
> node that you can't do anything with. The current implementation
> allows you to chdir(), opendir(), etc, those directory
> nodes, but the machinery to fully support those operations
> is missing so they just screw things up.
This would chomp the fdescfs functionality, IMHO. Why directory
file descriptors should behave differently then any other file
descriptor ?
I think that the actual solution for the walker problems is to
ignore the synthetic filesystems altogether. The information is
provided by sysctl vfs.conflist (note that the output is binary),
see VFCF_* flags, esp. VFCF_SYNTHETIC. The flag is correctly
set at least by procfs, devfs and fdescfs.
pgpZvNM0JAZ4R.pgp
Description: PGP signature
Re: bootstrapping gnat GCC on amd64
Just an update. Finally managed to get the i386 -> amd64 compiler to compile gcc 4.4.0. It took a few Makefile patches as for some reason, cross compilation breaks gnatmake. About to try to get the amd64 compiler to compile itself and run the test suite. Added a system-freebsd_x86_64.ads profile and checked all the other references to freebsd in the source. I've scripted the entire bootstrap process so it should be easy to produce binaries for a port. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: concurrent sysctl implementation
Hi, * vasanth raonaik wrote: > Hello Jt, > > I am a newbee in this alias. I am having a very basic question. It would be > really good if you could give me some of this information. > Could you please elaborate on what is the current architecture of sysctl > implementation and How the concurrency would benefit us. Right now sysctl is synchronized using the sysctl lock. The problem is that certain sysctls just block for a very long time (especially some of the GEOM ones). We also call sysctl when we execute new processes, to obtain a random number for the stack protector. This means we have quite a lot of contention on it. This lock needs to be there, because sysctls can be added and removed on demand. I think I discussed this with John Baldwin (right?) and I think we also have the issue that we cannot allow an unbounded amount of concurrent calls to sysctl, because sysctl wires memory. A solution would be to solve it as follows: - Use a semaphore, initialized to some insane high value to put an upper limit on the amount of concurrent sysctl calls. I'm not sure whether this is really needed. Maybe this issue is not as serious as we think it is. - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up the lock when we traverse parts of the sysctl tree that has dynamically created entries. -- Ed Schouten WWW: http://80386.nl/ pgpVFgnEuH1Cq.pgp Description: PGP signature
Re: fdescfs brokenness
On Fri, May 08, 2009 at 11:12:03PM +0300, Kostik Belousov wrote:
> On Thu, May 07, 2009 at 08:07:46PM -0700, Tim Kientzle wrote:
> > Colin Percival recently pointed out some issues
> > with tar and fdescfs. Part of the problem
> > here is tar; I need to rethink some of the
> > traversal logic.
> > But fdescfs is really wonky:
> > * This is a nit, but: ls /dev/fd/18 should not
> >return EBADF; it should return ENOENT, just
> >like any other reference to a non-existent filename.
> >(Just because a filename reflects a file descriptor
> >does not mean it is a file descriptor.)
> This is a traditional behaviour for fdescfs. According to man page,
> open("dev/fd/N") shall be equivalent to fcntl(N, F_DUPFD, 0).
> Solaris behaviour is the same.
On open, yes, but stat behaves differently on a Solaris 10 machine here.
A valid but unallocated fd number will still stat as a character
device, like an allocated fd.
% ls -l /dev/fd/0 /dev/fd/999
crw-rw-rw- 1 root root 320, 0 May 9 00:06 /dev/fd/0
crw-rw-rw- 1 root root 320, 999 May 9 00:06 /dev/fd/999
By the way, both FreeBSD and Solaris also behave strangely if you try to
access fd numbers 1<<32 or higher.
Linux seems to behave strangely as well: the fds show up as symlinks,
some of which do not contain valid file names but can still be opened.
However, a command like
{ read x <&5; read y > * The fairly routine recursive directory walker
> >below gets hung in fdescfs. It appears that
> >the two opendir() invocations active at the
> >same time interfere with each other.
> What you mean by "gets hung" ? In my limited testing, it works.
> Opendir creates a new directory in /dir/fd by the mere fact of opening
> the directory. So it walks into that dir, returning to step 1.
> > * A similar chdir()-based version of the directory
> >walker below breaks badly; you can chdir() into
> >a directory under /dev/fd, but you can't chdir("..")
> >to get back out of it. (This is the particular
> >problem that tar is running afoul of.)
> Not sure about this one. I think that fdescfs vnodes do not support
> lookup on anything not being root of the fdescfs.
> > * Running "find /dev/fd" generates bogus ENOENT errors
> >because you can opendir() a directory inside of /dev/fd,
> >and read the entries, but you can't access those entries
> >because path searches don't work through fdescfs.
> Again, this may be a consequence of the previous issue.
> > I think the right solution here is to add a VOP_ACCESS
> > handler to fdescfs that bars all access to directory
> > nodes under /dev/fd. Basically, if your program has a
> > directory open, that should be reflected as a directory
> > node that you can't do anything with. The current implementation
> > allows you to chdir(), opendir(), etc, those directory
> > nodes, but the machinery to fully support those operations
> > is missing so they just screw things up.
> This would chomp the fdescfs functionality, IMHO. Why directory
> file descriptors should behave differently then any other file
> descriptor ?
Linux and Solaris do not have these problems because their /dev/fd does
not copy stat information from the underlying file, instead showing a
character device (Solaris) or a symlink (Linux). I think a character
device would fit best, because you can do little else with it than open
it. The open operation is also different from opening the underlying
file because it does not create a new open file description.
devfs's /dev/fd/0, /dev/fd/1 and /dev/fd/2 work like this as well: they
always show up as character devices no matter what the underlying file
is. When opened, they duplicate the respective fd just like the full
/dev/fd does. (These are located at the end of /sys/kern/kern_descrip.c.)
Apparently someone noticed earlier this could be a problem, because the
R and X mode bits are cleared from directories that show up in /dev/fd.
It does not come as a surprise to me that that hack does not work.
> I think that the actual solution for the walker problems is to
> ignore the synthetic filesystems altogether. The information is
> provided by sysctl vfs.conflist (note that the output is binary),
> see VFCF_* flags, esp. VFCF_SYNTHETIC. The flag is correctly
> set at least by procfs, devfs and fdescfs.
I think it should be possible to write a directory walker program using
only standard interfaces.
--
Jilles Tjoelker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: concurrent sysctl implementation
Ed, Thanks :) I'll be implementing this as discussed over the next few months thanks for the technical detail I've been extremely busy with finals. I will write the list with my thoughts within the next week, sorry for the delay. =jt On May 8, 2009, at 17:41, Ed Schouten wrote: Hi, * vasanth raonaik wrote: Hello Jt, I am a newbee in this alias. I am having a very basic question. It would be really good if you could give me some of this information. Could you please elaborate on what is the current architecture of sysctl implementation and How the concurrency would benefit us. Right now sysctl is synchronized using the sysctl lock. The problem is that certain sysctls just block for a very long time (especially some of the GEOM ones). We also call sysctl when we execute new processes, to obtain a random number for the stack protector. This means we have quite a lot of contention on it. This lock needs to be there, because sysctls can be added and removed on demand. I think I discussed this with John Baldwin (right?) and I think we also have the issue that we cannot allow an unbounded amount of concurrent calls to sysctl, because sysctl wires memory. A solution would be to solve it as follows: - Use a semaphore, initialized to some insane high value to put an upper limit on the amount of concurrent sysctl calls. I'm not sure whether this is really needed. Maybe this issue is not as serious as we think it is. - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up the lock when we traverse parts of the sysctl tree that has dynamically created entries. -- Ed Schouten WWW: http://80386.nl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
