Re: bleh. Re: ufs_rename panic
:The problems all arise from the fact that we unlock the source :while we look up the destination, and when we return to relookup :the source, it may have changed/moved/disappeared. The reason to :unlock the source before looking up the destination was to avoid :deadlocking against ourselves on a lock that we held associated :with the source. Since we now allow recursive locks on vnodes, it :is no longer necessary to release the source before looking up :the destination. So, it seems to me that the correct fix is to :*not* release the source after looking it up, but rather hold it :locked while we look up the destination. We can completely get :rid of relookup and lots of other hairy code and generally make :rename much simpler. Am I missing something here? : : ~Kirk That was the first thing I thought of, but unfortunately it is still possible to deadlock against another process... for example, a process doing an (unrelated) rename in the reverse direction. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bleh. Re: ufs_rename panic
The problems all arise from the fact that we unlock the source while we look up the destination, and when we return to relookup the source, it may have changed/moved/disappeared. The reason to unlock the source before looking up the destination was to avoid deadlocking against ourselves on a lock that we held associated with the source. Since we now allow recursive locks on vnodes, it is no longer necessary to release the source before looking up the destination. So, it seems to me that the correct fix is to *not* release the source after looking it up, but rather hold it locked while we look up the destination. We can completely get rid of relookup and lots of other hairy code and generally make rename much simpler. Am I missing something here? ~Kirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setjmp/longjmp
Right, that was my question too, doesent seem connected with pre-emptive kernels... - Original Message - From: "Greg Lehey" <[EMAIL PROTECTED]> To: "Julian Elischer" <[EMAIL PROTECTED]> Cc: "Peter Pentchev" <[EMAIL PROTECTED]>; "Gersh" <[EMAIL PROTECTED]>; "Bernd Walter" <[EMAIL PROTECTED]>; "Anjali Kulkarni" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 03, 2001 6:14 AM Subject: Re: setjmp/longjmp > On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote: > > > > > > On Tue, 2 Oct 2001, Peter Pentchev wrote: > > > >> On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: > >>> [Format recovered--see http://www.lemis.com/email/email-format.html] > >>> > >>> On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: > On Fri, 28 Sep 2001, Gersh wrote: > > On Fri, 28 Sep 2001, Bernd Walter wrote: > >> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: > >>> Does anyone know whether it is advisable or not to use > >>> setjmp/longjmp within kernel code? I could not see any > >>> setjmp/longjmp in kernel source code. Is there a good reason for > >>> this or can it be used? > >> > >> You need to look again, it's used in several places in the kernel. > > > > Look at sys/i386/i386/db_interface.c > > Yeah but it would probably be a pretty bad idea to use it without > very careful thought. Especialy with the kernel becoming > pre-emptable in the future.. > >>> > >>> Can you think of a scenario where it wouldn't work? Preemption > >>> doesn't tear stacks apart, right? > >> > >> How about a case of a longjmp() back from under an acquired lock/mutex? > >> Like function A sets up a jump buffer, calls function B, B acquires > >> a lock, B calls C, C longjmp()'s back to A; what happens to the lock? > >> > >> It would work if A were aware of B's lock and the possibility of a code > >> path that would end up with it still being held; I presume that this is > >> what Julian meant by 'very careful thought'. > > > > pretty much... > > That's wrong, of course, but I don't see what this has to do with > preemptive kernels. This is the same incorrect usages as performing > malloc() and then longjmp()ing over the free(). > > Greg > -- > See complete headers for address and phone numbers > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory allocation question
: :Dwayne wrote: :> I'm creating an app where I want to use memory to store data so I :> can get at it quickly. The problem is, I can't afford the delays that :> would occur if the memory gets swapped out. Is there any way in FreeBSD :> to allocate memory so that the VM system won't swap it out? :> :I think mlock(2) is what you want. : :Maxime Henrion :-- :Don't be fooled by cheap finnish imitations ; BSD is the One True Code Don't use mlock(). Use SysV Shared memory segments. If you tell the kernel to use physical ram for SysV shared memory (kern.ipc.shm_use_phys=1) then any shm segments you allocate (see manual pages for shmctl, shmget, and shmat) will reside in unswappable shared memory. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
Greg Shenaut <[EMAIL PROTECTED]> types: > In message <[EMAIL PROTECTED]>, void cleopede: > >On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote: > >> Is there any reason why the "unbreakable space" (0xa0) shouldn't be > >> the only kind of space character used/allowed in filenames? > >Any character except for '/' is allowed in filenames, and I believe it's > >been that way since the dawn of time. You can't use nul either, and both have been true since v6. > Yes, but I mention it because if 0xa0 were used instead of space > in filenames, then they wouldn't be split into several arguments > and nothing special would need to be done in "for x in * ;" loops > or elsewhere to handle them, but the names would still look the same > to users. All the other characters that are magic to the shell - newline being the obvious example - will still cause problems. If you're going to use this to solve the problem, you need to go to something live VMS or MVS, and limit file names to alphanumerics plus a small set of delimiters. The usual solution for this kind of thing is to extend the shell. Shell scripts kept breaking trying tod deal with arguments with strange characters in them until the "$@" mechanism was added. I wonder how many scripts would break - or stop breaking :-) if we changed the shell so that "*" expanded like "$@"? http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]> Greg Shenaut writes:
: But you have to admit, space is a character that has caused many
: problems in Unix filenames, because of the other Unix tradition of
: space-delimited word record handling. I usually use an underscore,
: myself, if I want a space-like separation in a filename, but I
: could (and have) used 0xa0 for a similar purpose.
:
: Just out of curiosity, what would be an instance where you have
: wanted a space in a filename and wouldn't have been satisfied with
: 0xa0 instead of 0x20?
Where 0xa0 doesn't exist in the local? To be honest, up until this
thread I'd never heard of ASCII defining a unbreakable space as 0xa0.
That's because ASCII doesn't define it (but ISO 8859-1 might). I also
have a bad feeling that this might have implications for NFS file
systems as well where 0xa0 and 0x20 might mean different things to the
remote host.
And what about '"`~<>?[]{}\|)(*&^$ as well. All of these (and maybe
others) can cause problems as well.
In short, fix the broken shell scripts, not the filesystem. You
aren't fixing the real problem, just one small slice of it.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]> Giorgos Keramidas writes: : Greg Shenaut <[EMAIL PROTECTED]> wrote: : > : > I just throw out the idea--as for where to enforce such a convention, : > I agree that the file-system definition may not be the best place, : > but it might be the *easiest* place (spaces could be silently mapped : > to 0xa0's). : : Please don't even think about it. When I write a space, I mean a space, and : silently doing things behind my back, is something I have not been used to : expecting from Unix. Too much would break if you were to do force the filesystem to reject/map spaces like that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]>, Giorgos Keramidas cleopede: >Greg Shenaut <[EMAIL PROTECTED]> wrote: >> >> Just out of curiosity, what would be an instance where you have >> wanted a space in a filename and wouldn't have been satisfied with >> 0xa0 instead of 0x20? > >All of them. Space is so conveniently placed under the tip of my thumb. >To type 0xa0 I would hav to use exotic keystroke combos like: > > Left_Alt + Num_1 + Num_6 + Num_0 > >and that's a real pain to type. I just type ALT(space). It's even easier than SHIFT(-) (underscore). Anyway, I have found using 0xa0 (and underscore) very handy to prevent the kinds of contortions necessary when dealing with filenames and other text using word-oriented tools. I really don't think that space characters belong in filenames, but that's just my opinion. Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pkg_create help needed.
I need to take a directory of 'stuff' which includes a script install.sh and make it into a package.. I have had some success but it's not quite right.. What I'd like to make it do is: unpack the 'stuff' into a temporary directory somewhere. run the install script delete the install directory The trouble is that I can't work out how to get the files unpacked there and have the install script get them from there.. I can get it to unpack them into the final locations, and I can get the install script to run and find them there, but I need the install script to modify stuff and I'd rather have it all done in the temp directory if possible, and then istalled into the final location.. also I have can not make the @srcdir option work in the packing list.. does it work? (-s seems to work) julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patch #3 (was Re: bleh. Re: ufs_rename panic)
: :Matt Dillon wrote: :> Here is the latest patch I have. It appears to completely solve the :> problem. I have shims in unionfs and nfs for the moment. : :This seems rather large compared to Ian Dowse's version.. Are you sure that :you're doing this the right way? Adding a whole new locking mechanism :when the simple VRENAME flag to be enough seems like a bit of overkill.. Ian's doesn't fix any of the filesystem semantics bugs, it only prevents the panic from occuring. For example, if you have two hardlinked files residing in different directories both get renamed simultaniously, one of the rename()s can fail even though there is no conflict. If you have a simultanious rmdir() and rename(), the rename() can return an unexpected error code. And so forth. If you remove the filesystem semantics fixes from my patch you essentially get Ian's patch except that I integrated the vnode flag in namei/lookup whereas Ian handles it manually in the syscall code. Also, Ian's patch only effects system calls. It doesn't do the same fixes for nfs (server side) or unionfs. -Matt :I'm not criticizing your work, I am just wondering if you have considered :Ian's work and feel that it is wrong or the wrong direction.. His certainly :appears more elegant than yours so I want to understand why you feel yours :is better than his. : :freebsd-hackers :Message-id: <[EMAIL PROTECTED]> : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :"All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patch #3 (was Re: bleh. Re: ufs_rename panic)
Matt Dillon wrote: > Here is the latest patch I have. It appears to completely solve the > problem. I have shims in unionfs and nfs for the moment. This seems rather large compared to Ian Dowse's version.. Are you sure that you're doing this the right way? Adding a whole new locking mechanism when the simple VRENAME flag to be enough seems like a bit of overkill.. I'm not criticizing your work, I am just wondering if you have considered Ian's work and feel that it is wrong or the wrong direction.. His certainly appears more elegant than yours so I want to understand why you feel yours is better than his. freebsd-hackers Message-id: <[EMAIL PROTECTED]> Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setjmp/longjmp
On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote: > > > On Tue, 2 Oct 2001, Peter Pentchev wrote: > >> On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: >>> [Format recovered--see http://www.lemis.com/email/email-format.html] >>> >>> On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: On Fri, 28 Sep 2001, Gersh wrote: > On Fri, 28 Sep 2001, Bernd Walter wrote: >> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: >>> Does anyone know whether it is advisable or not to use >>> setjmp/longjmp within kernel code? I could not see any >>> setjmp/longjmp in kernel source code. Is there a good reason for >>> this or can it be used? >> >> You need to look again, it's used in several places in the kernel. > > Look at sys/i386/i386/db_interface.c Yeah but it would probably be a pretty bad idea to use it without very careful thought. Especialy with the kernel becoming pre-emptable in the future.. >>> >>> Can you think of a scenario where it wouldn't work? Preemption >>> doesn't tear stacks apart, right? >> >> How about a case of a longjmp() back from under an acquired lock/mutex? >> Like function A sets up a jump buffer, calls function B, B acquires >> a lock, B calls C, C longjmp()'s back to A; what happens to the lock? >> >> It would work if A were aware of B's lock and the possibility of a code >> path that would end up with it still being held; I presume that this is >> what Julian meant by 'very careful thought'. > > pretty much... That's wrong, of course, but I don't see what this has to do with preemptive kernels. This is the same incorrect usages as performing malloc() and then longjmp()ing over the free(). Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
Greg Shenaut <[EMAIL PROTECTED]> wrote: > > Just out of curiosity, what would be an instance where you have > wanted a space in a filename and wouldn't have been satisfied with > 0xa0 instead of 0x20? All of them. Space is so conveniently placed under the tip of my thumb. To type 0xa0 I would hav to use exotic keystroke combos like: Left_Alt + Num_1 + Num_6 + Num_0 and that's a real pain to type. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory allocation question
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >Hi, > > I'm creating an app where I want to use memory to store data so I >can get at it quickly. The problem is, I can't afford the delays that >would occur if the memory gets swapped out. Is there any way in FreeBSD >to allocate memory so that the VM system won't swap it out? mlock(2) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]>, Giorgos Keramidas cleopede: >Greg Shenaut <[EMAIL PROTECTED]> wrote: >> >> I just throw out the idea--as for where to enforce such a convention, >> I agree that the file-system definition may not be the best place, >> but it might be the *easiest* place (spaces could be silently mapped >> to 0xa0's). > >Please don't even think about it. When I write a space, I mean a space, and >silently doing things behind my back, is something I have not been used to >expecting from Unix. Right. Easiest is not necessarily best, in this case for exactly your reason. If you want a space in a filename, the Unix tradition clearly favors your having one. But you have to admit, space is a character that has caused many problems in Unix filenames, because of the other Unix tradition of space-delimited word record handling. I usually use an underscore, myself, if I want a space-like separation in a filename, but I could (and have) used 0xa0 for a similar purpose. Just out of curiosity, what would be an instance where you have wanted a space in a filename and wouldn't have been satisfied with 0xa0 instead of 0x20? Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
patch #3 (was Re: bleh. Re: ufs_rename panic)
Here is the latest patch I have. It appears to completely solve the
problem. I have shims in unionfs and nfs for the moment.
The patch is against -stable.
* Implements SOFTLOCKLEAF namei() option
* Implements EAGAIN error & appropriate tsleep/retry code
* Universal for rename() & rmdir(). Final patch will also probably
implement it on unlink() to solve (pre-existing) unlink/rename regular
file race.
* Tested very well w/ UFS, should be compatible with and work for
direct access to other filesystems that still use IN_RENAME.
* Tested for collision probability. Answer: Very low even when
one tries on purpose. There is no need to implement a more
sophisticated fine-grained tsleep.
-Matt
Index: kern/vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.3
diff -u -r1.38.2.3 vfs_lookup.c
--- kern/vfs_lookup.c 2001/08/31 19:36:49 1.38.2.3
+++ kern/vfs_lookup.c 2001/10/02 20:06:33
@@ -372,6 +372,11 @@
error = EISDIR;
goto bad;
}
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ if ((error = vsetsoftlock(dp)) != 0)
+ goto bad;
+ VREF(dp);
+ }
if (wantparent) {
ndp->ni_dvp = dp;
VREF(dp);
@@ -565,13 +570,17 @@
error = EROFS;
goto bad2;
}
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ if ((error = vsetsoftlock(dp)) != 0)
+ goto bad2;
+ VREF(dp);
+ }
if (cnp->cn_flags & SAVESTART) {
ndp->ni_startdir = ndp->ni_dvp;
VREF(ndp->ni_startdir);
}
if (!wantparent)
vrele(ndp->ni_dvp);
-
if ((cnp->cn_flags & LOCKLEAF) == 0)
VOP_UNLOCK(dp, 0, p);
return (0);
@@ -654,6 +663,11 @@
error = ENOTDIR;
goto bad;
}
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ if ((error = vsetsoftlock(dp)) != 0)
+ goto bad;
+ VREF(dp);
+ }
if (!(cnp->cn_flags & LOCKLEAF))
VOP_UNLOCK(dp, 0, p);
*vpp = dp;
@@ -707,6 +721,11 @@
error = EROFS;
goto bad2;
}
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ if ((error = vsetsoftlock(dp)) != 0)
+ goto bad2;
+ VREF(dp);
+ }
/* ASSERT(dvp == ndp->ni_startdir) */
if (cnp->cn_flags & SAVESTART)
VREF(dvp);
@@ -715,8 +734,9 @@
vrele(dvp);
if (vn_canvmio(dp) == TRUE &&
- ((cnp->cn_flags & (NOOBJ|LOCKLEAF)) == LOCKLEAF))
+ ((cnp->cn_flags & (NOOBJ|LOCKLEAF)) == LOCKLEAF)) {
vfs_object_create(dp, cnp->cn_proc, cnp->cn_cred);
+ }
if ((cnp->cn_flags & LOCKLEAF) == 0)
VOP_UNLOCK(dp, 0, p);
Index: kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.249.2.11
diff -u -r1.249.2.11 vfs_subr.c
--- kern/vfs_subr.c 2001/09/11 09:49:53 1.249.2.11
+++ kern/vfs_subr.c 2001/10/02 22:55:38
@@ -130,6 +132,8 @@
#endif
struct nfs_public nfs_pub; /* publicly exported FS */
static vm_zone_t vnode_zone;
+static int vagain_count = 1;
+static int vagain_waiting = 0;
/*
* The workitem queue.
@@ -2927,6 +2963,13 @@
struct nameidata *ndp;
const uint flags;
{
+ if (!(flags & NDF_NO_FREE_SOFTLOCKLEAF) &&
+ (ndp->ni_cnd.cn_flags & SOFTLOCKLEAF) &&
+ ndp->ni_vp) {
+ vclearsoftlock(ndp->ni_vp);
+ ndp->ni_cnd.cn_flags &= ~SOFTLOCKLEAF;
+ vrele(ndp->ni_vp);
+ }
if (!(flags & NDF_NO_FREE_PNBUF) &&
(ndp->ni_cnd.cn_flags & HASBUF)) {
zfree(namei_zone, ndp->ni_cnd.cn_pnbuf);
@@ -2955,3 +2998,55 @@
ndp->ni_startdir = NULL;
}
}
+
+/*
+ * vsetsoftlock() -set the VSOFTLOCK flag on the vnode, return
+ * EAGAIN if it has already been set by someone else.
+ *
+ * note: we could further refine the collision by setting a VSOFTLOCKCOLL
+ * flag and then only waking up waiters when the colliding vnode is
+ * released. However, this sort of collision does not happen often
+ * enough for such an addition to yield any improvement in performance.
+ */
+
+int
+vsetsoftlock(struct vnode *vp)
+{
+ int s;
+ int error = 0;
+
+ s = splbio();
+ if (vp->v_flag & VSOFTLOCK)
+
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
Greg Shenaut <[EMAIL PROTECTED]> wrote: > > I just throw out the idea--as for where to enforce such a convention, > I agree that the file-system definition may not be the best place, > but it might be the *easiest* place (spaces could be silently mapped > to 0xa0's). Please don't even think about it. When I write a space, I mean a space, and silently doing things behind my back, is something I have not been used to expecting from Unix. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Doubt of system(3)
* David Taylor <[EMAIL PROTECTED]> [011002 16:02] wrote: > On Tue, 02 Oct 2001, Alfred Perlstein wrote: > > * Peter Pentchev <[EMAIL PROTECTED]> [011002 05:21] wrote: > > > On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote: > > > [snip] > > > > IMO, the below patch is probably the best solution. > > > > > > Yep, it also fixes the fact that the return value from wait4() needs > > > to be preserved, at least for the return statement of __system(). > > > > Aaah! Forgot about it, I'm going to upgrade my workstation > > now and commit it if it works, probably tonight. > > > > If someone else can test it earlier, by all means commit it. > > Just to say that as I did a make world today, I took the opportunity to test > the patch, and it does fix the bug. Thanks for taking the time to do this and thanks for the feedback. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory allocation question
Dwayne wrote: > I'm creating an app where I want to use memory to store data so I > can get at it quickly. The problem is, I can't afford the delays that > would occur if the memory gets swapped out. Is there any way in FreeBSD > to allocate memory so that the VM system won't swap it out? > I think mlock(2) is what you want. Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory allocation question
Dwayne wrote: > > Hi, > > I'm creating an app where I want to use memory to store data so I > can get at it quickly. The problem is, I can't afford the delays that > would occur if the memory gets swapped out. Is there any way in FreeBSD > to allocate memory so that the VM system won't swap it out? It's not a 100% guarentee IIRC, but I think madvise(2) can tell FreeBSD to try it's best to not swap out parts of memory. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Memory allocation question
Hi, I'm creating an app where I want to use memory to store data so I can get at it quickly. The problem is, I can't afford the delays that would occur if the memory gets swapped out. Is there any way in FreeBSD to allocate memory so that the VM system won't swap it out? Thanks, DMK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Doubt of system(3)
On Tue, 02 Oct 2001, Alfred Perlstein wrote: > * Peter Pentchev <[EMAIL PROTECTED]> [011002 05:21] wrote: > > On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote: > > [snip] > > > IMO, the below patch is probably the best solution. > > > > Yep, it also fixes the fact that the return value from wait4() needs > > to be preserved, at least for the return statement of __system(). > > Aaah! Forgot about it, I'm going to upgrade my workstation > now and commit it if it works, probably tonight. > > If someone else can test it earlier, by all means commit it. Just to say that as I did a make world today, I took the opportunity to test the patch, and it does fix the bug. (Old behaviour: davidt@gattaca:~/C/system-bug$ ./test Parent: Child A pid = 26271 Calling system... Child A: exiting Child B running - pid 26273 Child B: Sending parent (26270) SIGFPE to interrupt wait... System has returned Child B entering busy loop... Child B still running... Parent exiting - child b should have also exited... davidt@gattaca:~/C/system-bug$ Child B still running... killall test2 Terminated New behaviour: davidt@gattaca:~/C/system-bug$ ./test Parent: Child A pid = 27944 Calling system... Child A: exiting Child B running - pid 27946 Child B: Sending parent (27943) SIGFPE to interrupt wait... Child B entering busy loop... Child B still running... Child B still running... Child B still running... ^Z [1]+ Stopped ./test davidt@gattaca:~/C/system-bug$ bg [1]+ ./test & davidt@gattaca:~/C/system-bug$ Child B still running... kill 27946 Terminated System has returned Parent exiting - child b should have also exited... davidt@gattaca:~/C/system-bug$ ) However, I won't be able to commit it, since I'm not a committer :) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bleh. Re: ufs_rename panic
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>What I've done is add a SOFTLOCKLEAF capability to namei(). If set, and
>the file/directory exists, namei() will generate an extra VREF() on
>the vnode and set the VSOFTLOCK flag in vp->v_flag. If the vnode already
>has VSOFTLOCK set, namei() will return EINVAL.
I just tried a more direct approach, which is to implement a flag
at the vnode layer that is roughly equivalent to UFS's IN_RENAME
flag. This keeps the changes local to vfs_syscalls.c except for
the addition of a new vnode flag in vnode.h.
A patch is below. It doesn't include the changes to remove IN_RENAME
etc, but these could be done later anyway.
The basic idea is that the rename syscall locks the source node
just for long enough to mark it with VRENAME. It then keeps an
extra reference on the source node so that it can clear VRENAME
before returning. The syscalls unlink(), rmdir() and rename() also
check for VRENAME before proceeding with the operation, and act
appropriately if it is found set. One case that is not being handled
well is where the target of a rename has VRENAME set; the patch just
causes rename to return EINVAL, but a better approach would be to
unlock everything and try again. I don't know how to deal with the
case of vn_lock(fvp, ...) failing at the end of rename() either.
Only lightly tested, so expect lots of bugs...
Ian
Index: sys/vnode.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/sys/vnode.h,v
retrieving revision 1.157
diff -u -r1.157 vnode.h
--- sys/vnode.h 13 Sep 2001 22:52:42 - 1.157
+++ sys/vnode.h 2 Oct 2001 19:06:41 -
@@ -163,8 +163,8 @@
#defineVXLOCK 0x00100 /* vnode is locked to change underlying type */
#defineVXWANT 0x00200 /* thread is waiting for vnode */
#defineVBWAIT 0x00400 /* waiting for output to complete */
+#defineVRENAME 0x00800 /* rename operation on progress */
#defineVNOSYNC 0x01000 /* unlinked, stop syncing */
-/* open for business0x01000 */
#defineVOBJBUF 0x02000 /* Allocate buffers in VM object */
#defineVCOPYONWRITE0x04000 /* vnode is doing copy-on-write */
#defineVAGE0x08000 /* Insert vnode at head of free list */
Index: kern/vfs_syscalls.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.206
diff -u -r1.206 vfs_syscalls.c
--- kern/vfs_syscalls.c 22 Sep 2001 03:07:41 - 1.206
+++ kern/vfs_syscalls.c 2 Oct 2001 20:29:54 -
@@ -1573,6 +1573,9 @@
if (vp->v_flag & VROOT)
error = EBUSY;
}
+ /* Claim that the node is already gone if it is being renamed. */
+ if (vp->v_flag & VRENAME)
+ error = ENOENT;
if (vn_start_write(nd.ni_dvp, &mp, V_NOWAIT) != 0) {
NDFREE(&nd, NDF_ONLY_PNBUF);
vrele(vp);
@@ -2879,20 +2882,29 @@
struct mount *mp;
struct vnode *tvp, *fvp, *tdvp;
struct nameidata fromnd, tond;
- int error;
+ int err1, error;
bwillwrite();
- NDINIT(&fromnd, DELETE, WANTPARENT | SAVESTART, UIO_USERSPACE,
- SCARG(uap, from), td);
+ NDINIT(&fromnd, DELETE, WANTPARENT | LOCKLEAF | SAVESTART,
+ UIO_USERSPACE, SCARG(uap, from), td);
if ((error = namei(&fromnd)) != 0)
return (error);
fvp = fromnd.ni_vp;
- if ((error = vn_start_write(fvp, &mp, V_WAIT | PCATCH)) != 0) {
+ if (fvp->v_flag & VRENAME)
+ /* The node is being renamed; claim it has already gone. */
+ error = ENOENT;
+ if (!error)
+ error = vn_start_write(fvp, &mp, V_WAIT | PCATCH);
+ if (error) {
NDFREE(&fromnd, NDF_ONLY_PNBUF);
vrele(fromnd.ni_dvp);
- vrele(fvp);
+ vput(fvp);
+ fvp = NULL;
goto out1;
}
+ fvp->v_flag |= VRENAME;
+ vref(fvp);
+ VOP_UNLOCK(fvp, 0, td);
NDINIT(&tond, RENAME, LOCKPARENT | LOCKLEAF | NOCACHE | SAVESTART | NOOBJ,
UIO_USERSPACE, SCARG(uap, to), td);
if (fromnd.ni_vp->v_type == VDIR)
@@ -2929,6 +2941,10 @@
!bcmp(fromnd.ni_cnd.cn_nameptr, tond.ni_cnd.cn_nameptr,
fromnd.ni_cnd.cn_namelen))
error = -1;
+ if (tvp != NULL && (tvp->v_flag & VRENAME)) {
+ /* XXX, should just unlock everything and retry. */
+ error = EINVAL;
+ }
out:
if (!error) {
VOP_LEASE(tdvp, td, td->td_proc->p_ucred, LEASE_WRITE);
@@ -2961,6 +2977,18 @@
ASSERT_VOP_UNLOCKED(tond.ni_dvp, "rename");
ASSERT_VOP_UNLOCKED(tond.ni_vp, "rename");
out1:
+ if (fvp != NULL) {
+ /* We set the VRENAME flag a
Cyclades Cyclom YeP (PCI) driver problems on a DELL PowerEdge 2550 (DUAL)
Hello,
There are problems with the Cyclades Cyclom YeP driver. (see PR
i386/30965). I've put printf's in the driver code on several places to
check where the point is of hard locking and its seems to be on line 136
in the /usr/src/sys/pci/cy_pci.c in my situation.
-
case PLX_9050:
outw(ioport + CY_PLX_9050_ICS,
inw(ioport + CY_PLX_9050_ICS) |
CY_PLX_9050_ICS_IENABLE |
CY_PLX_9050_ICS_LOCAL_IENABLE);
-
This particular piece of code is hard-locking a DUAL PENTIUM III 933
DELL PowerEdge 2550 with 2 YeP (PCI) boards with a SINGLE CPU kernel.
(Doesn't even react on numlock key anymore)
I really need some enligtment on this.
Attached my kernel conf file and below the piece of code containg the lines.
static void
cy_attach(config_id, unit)
pcici_t config_id;
int unit;
{
vm_offset_t paddr;
void *vaddr;
u_int32_t ioport;
int adapter;
u_char plx_ver;
ioport = (u_int32_t) pci_conf_read(config_id, CY_PCI_BASE_ADDR1)
& ~0x3;
paddr = pci_conf_read(config_id, CY_PCI_BASE_ADDR2) & ~0xf;
#if 0
if (!pci_map_mem(config_id, CY_PCI_BASE_ADDR2, &vaddr, &paddr)) {
printf("cy%d: couldn't map shared memory\n", unit);
return;
};
#endif
vaddr = pmap_mapdev(paddr, 0x4000);
adapter = cyattach_common(vaddr, 1);
if (adapter < 0) {
/*
* No ports found. Release resources and punt.
*/
printf("cy%d: no ports found!\n", unit);
goto fail;
}
/*
* Allocate our interrupt.
* XXX Using the ISA interrupt handler directly is a bit of a
violation
* since it doesn't actually take the same argument. For
PCI, the
* argument is a void * token, but for ISA it is a unit. Since
* there is no overlap in PCI/ISA unit numbers for this
driver, and
* since the ISA driver must handle the interrupt anyway,
we use
* the unit number as the token even for PCI.
*/
if (
#ifdef CY_PCI_FASTINTR
!pci_map_int_right(config_id, (pci_inthand_t *)cyintr,
(void *)adapter, &tty_imask,
INTR_EXCL | INTR_FAST) &&
#endif
!pci_map_int_right(config_id, (pci_inthand_t *)cyintr,
(void *)adapter, &tty_imask, 0)) {
printf("cy%d: couldn't map interrupt\n", unit);
goto fail;
}
/*
* Enable the "local" interrupt input to generate a
* PCI interrupt.
*/
plx_ver = *((u_char *)vaddr + PLX_VER) & 0x0f;
switch (plx_ver) {
case PLX_9050:
outw(ioport + CY_PLX_9050_ICS,
inw(ioport + CY_PLX_9050_ICS) |
CY_PLX_9050_ICS_IENABLE |
CY_PLX_9050_ICS_LOCAL_IENABLE);
break;
case PLX_9060:
case PLX_9080:
default:/* Old board, use PLX_9060 values. */
outw(ioport + CY_PLX_9060_ICS,
inw(ioport + CY_PLX_9060_ICS) |
CY_PLX_9060_ICS_IENABLE |
CY_PLX_9060_ICS_LOCAL_IENABLE);
break;
}
return;
fail:
/* XXX should release any allocated virtual memory */
return;
}
#
# Dell POWER-EDGE 2550 Server kernel config
#
# Take Care : sio1removed
# ppc removed
# INET6 removed
# cyclades cy0 cy1 and cy2added
# options CY_FAST_INTERUPTadded
# options SC_DISABLE_REBOOT added (REQUIRED!!)
#
# DO NOT FORGET TO MODIFY THE BIOS SETTINGS ACCORDINGLY !!
#
# TRY TO GIVE EACH Cyclades YeP board IT'S OWN IRQ !!
#
machine i386
cpu I686_CPU
ident POWEREDGE-2550
maxusers256
#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
#optionsMATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
#optionsINET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
options MD_ROOT #MD is a potential root device
options NFS #Network Filesystem
#optionsNFS_ROOT#NFS usable as roo
Re: bleh. Re: ufs_rename panic
Ok, I'm adding -hackers... another email thread got going in -committers.
Here is a patch set for -stable. It isn't perfect but it does appear
to solve the problem. The one case I don't handle right is if you have
a hardlinked file and two renames in two different directories on the same
file occur at the same time... that will (improperly) return an error
code when, in fact, it's perfectly acceptable to do that.
This patch appears to fix the utterly trivial crash reproduction that
Yevgeniy was able to produce with a couple of simple race scripts running
in the background.
What I've done is add a SOFTLOCKLEAF capability to namei(). If set, and
the file/directory exists, namei() will generate an extra VREF() on
the vnode and set the VSOFTLOCK flag in vp->v_flag. If the vnode already
has VSOFTLOCK set, namei() will return EINVAL.
Then in rename() and rmdir() I set SOFTLOCKLEAF for the namei resolution
and, of course, clean things up when everything is done.
The ufs_rename() and ufs_rmdir() code no longer have to do the IN_RENAME
hack at all, because it's now handled.
This patch set does not yet include fixes to unionfs or the nfs server
and is for informational purposes only. Comments?
-Matt
Index: kern/vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.3
diff -u -r1.38.2.3 vfs_lookup.c
--- kern/vfs_lookup.c 2001/08/31 19:36:49 1.38.2.3
+++ kern/vfs_lookup.c 2001/10/02 19:04:21
@@ -372,11 +372,20 @@
error = EISDIR;
goto bad;
}
+ if ((cnp->cn_flags & SOFTLOCKLEAF) &&
+ (dp->v_flag & VSOFTLOCK)) {
+ error = EINVAL;
+ goto bad;
+ }
if (wantparent) {
ndp->ni_dvp = dp;
VREF(dp);
}
ndp->ni_vp = dp;
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ VREF(dp);
+ vsetsoftlock(dp);
+ }
if (!(cnp->cn_flags & (LOCKPARENT | LOCKLEAF)))
VOP_UNLOCK(dp, 0, p);
/* XXX This should probably move to the top of function. */
@@ -565,13 +574,20 @@
error = EROFS;
goto bad2;
}
+ if ((cnp->cn_flags & SOFTLOCKLEAF) && (dp->v_flag & VSOFTLOCK)) {
+ error = EINVAL;
+ goto bad2;
+ }
if (cnp->cn_flags & SAVESTART) {
ndp->ni_startdir = ndp->ni_dvp;
VREF(ndp->ni_startdir);
}
if (!wantparent)
vrele(ndp->ni_dvp);
-
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ VREF(dp);
+ vsetsoftlock(dp);
+ }
if ((cnp->cn_flags & LOCKLEAF) == 0)
VOP_UNLOCK(dp, 0, p);
return (0);
@@ -654,6 +670,15 @@
error = ENOTDIR;
goto bad;
}
+ if ((cnp->cn_flags & SOFTLOCKLEAF) &&
+ (dp->v_flag & VSOFTLOCK)) {
+ error = EINVAL;
+ goto bad;
+ }
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ VREF(dp);
+ vsetsoftlock(dp);
+ }
if (!(cnp->cn_flags & LOCKLEAF))
VOP_UNLOCK(dp, 0, p);
*vpp = dp;
@@ -707,6 +732,10 @@
error = EROFS;
goto bad2;
}
+ if ((cnp->cn_flags & SOFTLOCKLEAF) && (dp->v_flag & VSOFTLOCK)) {
+ error = EINVAL;
+ goto bad2;
+ }
/* ASSERT(dvp == ndp->ni_startdir) */
if (cnp->cn_flags & SAVESTART)
VREF(dvp);
@@ -718,6 +747,10 @@
((cnp->cn_flags & (NOOBJ|LOCKLEAF)) == LOCKLEAF))
vfs_object_create(dp, cnp->cn_proc, cnp->cn_cred);
+ if (cnp->cn_flags & SOFTLOCKLEAF) {
+ VREF(dp);
+ vsetsoftlock(dp);
+ }
if ((cnp->cn_flags & LOCKLEAF) == 0)
VOP_UNLOCK(dp, 0, p);
return (0);
Index: kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.249.2.11
diff -u -r1.249.2.11 vfs_subr.c
--- kern/vfs_subr.c 2001/09/11 09:49:53 1.249.2.11
+++ kern/vfs_subr.c 2001/10/02 18:45:55
@@ -2927,6 +2961,12 @@
struct nameidata *ndp;
const uint flags;
{
+ if (!(flags & NDF_NO_FREE_SOFTLOCKLEAF) &&
+ (ndp->ni_cnd.cn_flags & SOFTLOCKLEAF) &&
+ ndp->ni_vp) {
+ vclearsoftlock(ndp->ni_vp);
+ vrele(ndp->ni_vp);
+
Re: setjmp/longjmp
On Tue, 2 Oct 2001, Peter Pentchev wrote: > On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: > > [Format recovered--see http://www.lemis.com/email/email-format.html] > > > > On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: > > > On Fri, 28 Sep 2001, Gersh wrote: > > >> On Fri, 28 Sep 2001, Bernd Walter wrote: > > >>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: > > Does anyone know whether it is advisable or not to use > > setjmp/longjmp within kernel code? I could not see any > > setjmp/longjmp in kernel source code. Is there a good reason for > > this or can it be used? > > >>> > > >>> You need to look again, it's used in several places in the kernel. > > >> > > >> Look at sys/i386/i386/db_interface.c > > > > > > Yeah but it would probably be a pretty bad idea to use it without > > > very careful thought. Especialy with the kernel becoming > > > pre-emptable in the future.. > > > > Can you think of a scenario where it wouldn't work? Preemption > > doesn't tear stacks apart, right? > > How about a case of a longjmp() back from under an acquired lock/mutex? > Like function A sets up a jump buffer, calls function B, B acquires > a lock, B calls C, C longjmp()'s back to A; what happens to the lock? > > It would work if A were aware of B's lock and the possibility of a code > path that would end up with it still being held; I presume that this is > what Julian meant by 'very careful thought'. pretty much... > > G'luck, > Peter > > -- > Do you think anybody has ever had *precisely this thought* before? > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]>, void cleopede: >On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote: >> >> Is there any reason why the "unbreakable space" (0xa0) shouldn't be >> the only kind of space character used/allowed in filenames? > >Any character except for '/' is allowed in filenames, and I believe it's >been that way since the dawn of time. Yes, but I mention it because if 0xa0 were used instead of space in filenames, then they wouldn't be split into several arguments and nothing special would need to be done in "for x in * ;" loops or elsewhere to handle them, but the names would still look the same to users. I just throw out the idea--as for where to enforce such a convention, I agree that the file-system definition may not be the best place, but it might be the *easiest* place (spaces could be silently mapped to 0xa0's). Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dump/restore and DIRPREF
I recommend using cpdup ( /usr/ports/sysutils/cpdup ), mainly because you can ^C it and restart it at any time so it's a lot easier to play around with your directory dup'ing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ALT- (Was: how to make 'for' understand two words as a single argumen)
On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote: > > Is there any reason why the "unbreakable space" (0xa0) shouldn't be > the only kind of space character used/allowed in filenames? Any character except for '/' is allowed in filenames, and I believe it's been that way since the dawn of time. -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dump/restore and DIRPREF
> >After Kris's recent report of 'massive speedups' using dirpref, I've > >been toying with the idea of backing up my box, and then restoring them. > > > >However, backup/restore are so much faster than doing a tar/untar. > > > >If I do a backup of my FS, wipe the disk, will the 'restore' cause the > >same (ineffecient) directory layout to appear on disk? > > > >I wouldn't think so since the directory layout is controlled by the > >kernel, but I do know that dump/restore are much lower-layer tools than > >tar, so they may possibly have layout information embedded in them. > > > >Is my assumption correct? > > no. Actually, yes, but I didn't word it very well above. > Dump reads the raw device and finds everything by hand. > > Restore (like tar!) just open/write/close/chown regular files. So my assumption *is* correct that it won't matter if I use dump/restore to do the job, and that the lower-layer effeciencies of dump don't effect the resulting layout done by restore. Great, thanks for the quick response! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dump/restore and DIRPREF
In message <[EMAIL PROTECTED]>, Nate Williams writes : >After Kris's recent report of 'massive speedups' using dirpref, I've >been toying with the idea of backing up my box, and then restoring them. > >However, backup/restore are so much faster than doing a tar/untar. > >If I do a backup of my FS, wipe the disk, will the 'restore' cause the >same (ineffecient) directory layout to appear on disk? > >I wouldn't think so since the directory layout is controlled by the >kernel, but I do know that dump/restore are much lower-layer tools than >tar, so they may possibly have layout information embedded in them. > >Is my assumption correct? no. Dump reads the raw device and finds everything by hand. Restore (like tar!) just open/write/close/chown regular files. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dump/restore and DIRPREF
On Tue, Oct 02, 2001 at 11:05:00AM -0600, Nate Williams wrote: > If I do a backup of my FS, wipe the disk, will the 'restore' cause the > same (ineffecient) directory layout to appear on disk? > > I wouldn't think so since the directory layout is controlled by the > kernel, but I do know that dump/restore are much lower-layer tools than > tar, so they may possibly have layout information embedded in them. > > Is my assumption correct? No. Dump reads the raw disk directly, but restore doesn't. Dump needs to in order to find the actual location of holes in files, but recreating them can be done in userland by simply seeking over them so there's no need to write directly to the raw disk on restore. Assuming you can read the dumps and you don't care about the file permissions, you can restore as any user. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
dump/restore and DIRPREF
After Kris's recent report of 'massive speedups' using dirpref, I've been toying with the idea of backing up my box, and then restoring them. However, backup/restore are so much faster than doing a tar/untar. If I do a backup of my FS, wipe the disk, will the 'restore' cause the same (ineffecient) directory layout to appear on disk? I wouldn't think so since the directory layout is controlled by the kernel, but I do know that dump/restore are much lower-layer tools than tar, so they may possibly have layout information embedded in them. Is my assumption correct? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newbie question: filesystem i/o
* Egervary Gergely <[EMAIL PROTECTED]> [011002 11:00] wrote: > hi hackers, > > I'm quite new to FreeBSD but not in UN*X, please let me ask a question: > > I wonder that the filesystem performance under FreeBSD is so great. I'm > doing disk-to-disk file copies, like ``dd if=file1 of=file2 bs=64k'' and > the performance is much better than on other unices. Other systems use > 16k or 64k (or whatever MAXBSIZE is set to) chunks for sequential i/o, and > the disk seeks like an evil. On FreeBSD, the disk seeks _much_ less. > > probably FreeBSD is re-blocking the (contigous?) chunks, and does i/o with > huge blocks like several megabytes? How is it done technically? Is it the > filesystem, or the VM? > > could someone enlighten me please? :) Hmm.. http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0201549794 Also, you'll want to clarify what you mean by "most unicies", you can't compare apples and cold fusion, at least give us an orange, ok? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Doubt of system(3)
* Peter Pentchev <[EMAIL PROTECTED]> [011002 05:21] wrote: > On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote: > [snip] > > IMO, the below patch is probably the best solution. > > Yep, it also fixes the fact that the return value from wait4() needs > to be preserved, at least for the return statement of __system(). Aaah! Forgot about it, I'm going to upgrade my workstation now and commit it if it works, probably tonight. If someone else can test it earlier, by all means commit it. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
newbie question: filesystem i/o
hi hackers, I'm quite new to FreeBSD but not in UN*X, please let me ask a question: I wonder that the filesystem performance under FreeBSD is so great. I'm doing disk-to-disk file copies, like ``dd if=file1 of=file2 bs=64k'' and the performance is much better than on other unices. Other systems use 16k or 64k (or whatever MAXBSIZE is set to) chunks for sequential i/o, and the disk seeks like an evil. On FreeBSD, the disk seeks _much_ less. probably FreeBSD is re-blocking the (contigous?) chunks, and does i/o with huge blocks like several megabytes? How is it done technically? Is it the filesystem, or the VM? could someone enlighten me please? :) cheers, -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
compiling kernels from readonly source trees ?
[Bcc to -small as someone there might have had similar problems]
Hi,
I was trying to modify the picobsd build scripts so that the source
tree is entirely readonly. For the most part of it i think
i managed, the only missing part seems to be compilation of
new kernels.
config supports the "-d" command to set the destination directory,
but it appears that it insists on the config file being in
${SYS}/${ARCH}/conf/ as it derives other paths from the
current directory, such as
...
if (realpath("../..", srcdir) == NULL)
...
(void) snprintf(fname, sizeof(fname), "../../conf/options");
and maybe more places like this.
Am I wrong ? And if not, is there any plan to make config
handle config files in other places than ${SYS}/${ARCH}/conf ?
cheers
luigi
--+-
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
--+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to make 'for' understand two words as a single argument
Daniel C. Sobral([EMAIL PROTECTED])@2001.10.02 09:18:43 +:
> Stijn Hoop wrote:
> >
> > > Any way using `` won't work. for i in a "b c" d works, for instance, but
> > > there is not way that I know of that you can control the output this way
> > > using ``.
> >
> > Yes there is: set IFS to only contain a newline beforehand. That's my local
> > hack, your way is probably better :)
>
> But if you do that, you'll get a single argument back, instead of a
> number of arguments, some of which have space in the middle, or not?
you should save IFS somewhere, anyway.
you might do
[...]
OLDIFS="${IFS}"
IFS='
'
for i in "`command`"; do
IFS="${OLDIFS}"
echo "${i}" | read one two
othercommand ${one} more arguments -paramaters ${two}
IFS='
'
done
[...]
in bournish shells. i am a zsh user, so perhaps this won't work in
/bin/sh...
arguments should be parsed as expanded text, so it should not really
matter if you use them as subsequent arguments. the technique with
echo'ing the value through read splits it into the two variables.
does this make sense?
/k
--
> MCSE: Management Can't Send E-mail
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
PGP signature
ALT- (Was: how to make 'for' understand two words as a single argumen)
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" cleopede: >Stijn Hoop wrote: >> >> > Any way using `` won't work. for i in a "b c" d works, for instance, but >> > there is not way that I know of that you can control the output this way >> > using ``. >> >> Yes there is: set IFS to only contain a newline beforehand. That's my local >> hack, your way is probably better :) > >But if you do that, you'll get a single argument back, instead of a >number of arguments, some of which have space in the middle, or not? Is there any reason why the "unbreakable space" (0xa0) shouldn't be the only kind of space character used/allowed in filenames? Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setjmp/longjmp
On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: > [Format recovered--see http://www.lemis.com/email/email-format.html] > > On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: > > On Fri, 28 Sep 2001, Gersh wrote: > >> On Fri, 28 Sep 2001, Bernd Walter wrote: > >>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: > Does anyone know whether it is advisable or not to use > setjmp/longjmp within kernel code? I could not see any > setjmp/longjmp in kernel source code. Is there a good reason for > this or can it be used? > >>> > >>> You need to look again, it's used in several places in the kernel. > >> > >> Look at sys/i386/i386/db_interface.c > > > > Yeah but it would probably be a pretty bad idea to use it without > > very careful thought. Especialy with the kernel becoming > > pre-emptable in the future.. > > Can you think of a scenario where it wouldn't work? Preemption > doesn't tear stacks apart, right? How about a case of a longjmp() back from under an acquired lock/mutex? Like function A sets up a jump buffer, calls function B, B acquires a lock, B calls C, C longjmp()'s back to A; what happens to the lock? It would work if A were aware of B's lock and the possibility of a code path that would end up with it still being held; I presume that this is what Julian meant by 'very careful thought'. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to make 'for' understand two words as a single argument
Stijn Hoop wrote: > > > Any way using `` won't work. for i in a "b c" d works, for instance, but > > there is not way that I know of that you can control the output this way > > using ``. > > Yes there is: set IFS to only contain a newline beforehand. That's my local > hack, your way is probably better :) But if you do that, you'll get a single argument back, instead of a number of arguments, some of which have space in the middle, or not? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wow regex humor... I'm a geek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Doubt of system(3)
On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote:
[snip]
> IMO, the below patch is probably the best solution.
Yep, it also fixes the fact that the return value from wait4() needs
to be preserved, at least for the return statement of __system().
G'luck,
Peter
--
"yields falsehood, when appended to its quotation." yields falsehood, when appended to
its quotation.
> > cvs diff: Diffing .
> > Index: system.c
> > ===
> > RCS file: /home/ncvs/src/lib/libc/stdlib/system.c,v
> > retrieving revision 1.7
> > diff -u -r1.7 system.c
> > --- system.c2001/01/24 13:00:59 1.7
> > +++ system.c2001/09/29 21:55:41
> > @@ -53,7 +53,7 @@
> > __system(command)
> > const char *command;
> > {
> > - pid_t pid;
> > + pid_t pid, savedpid;
> > int pstat;
> > struct sigaction ign, intact, quitact;
> > sigset_t newsigblock, oldsigblock;
> > @@ -86,8 +86,9 @@
> > execl(_PATH_BSHELL, "sh", "-c", command, (char *)NULL);
> > _exit(127);
> > default:/* parent */
> > + savedpid = pid;
> > do {
> > - pid = _wait4(pid, &pstat, 0, (struct rusage *)0);
> > + pid = _wait4(savedpid, &pstat, 0, (struct rusage *)0);
> > } while (pid == -1 && errno == EINTR);
> > break;
> > }
> >
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
