Re: aps2file doesn't work on FreeBSD
On Sun, 16 Dec 2001, Anthony Schneider wrote: >Well, the reason I brought up $USER inheritance is that on linux, $USER >is root after an su to root, whereas on FreeBSD, the $USER is the same >as before the su. [Line wrap at 72, please] Excerpt from su(1): --- By default, the environment is unmodified with the exception of USER, HOME, and SHELL. HOME and SHELL are set to the target login's default values. USER is set to the target login, unless the target login has a user ID of 0, in which case it is unmodified. The invoked shell is the target login's. This is the traditional behavior of su. -l Simulate a full login. --- You are observing none other than the expected behavior. I have never seen Linux (GNU) su do things any differently in this regard. If they do, it's broken. Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aps2file doesn't work on FreeBSD
Linux: anthony:/home/anthony:9% uname -a Linux lappy.slc.edu 2.2.17-21mdk #1 Thu Oct 5 13:16:08 CEST 2000 i686 unknown anthony:/home/anthony:10% su Password: [root@lappy anthony]# echo $USER root [root@lappy anthony]# exit anthony:/home/anthony:11% su -l Password: [root@lappy /root]# echo $USER root [root@lappy /root]# FreeBSD: anthony:/home/anthony:20% uname -a FreeBSD flack.slc.edu 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 anthony:/home/anthony:21% su Password: flack# echo $USER anthony flack# exit anthony:/home/anthony:22% su -l Password: flack# echo $USER root flack# logout anthony:/home/anthony:23% From 'info su' on my linux box: By default, `su' does not change the current directory. It sets the environment variables `HOME' and `SHELL' from the password entry for USER, and if USER is not the super-user, sets `USER' and `LOGNAME' to USER. By default, the shell is not a login shell. su version (on my linux box): [root@lappy anthony]# su --version su (GNU sh-utils) 2.0 Written by David MacKenzie. Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [root@lappy anthony]# Perhaps it's time to contact gnu? -Anthony. [ and apologies for the line wrapping ] On Mon, Dec 17, 2001 at 03:09:19AM -0500, Brandon D. Valentine wrote: > On Sun, 16 Dec 2001, Anthony Schneider wrote: > > >Well, the reason I brought up $USER inheritance is that on linux, $USER > >is root after an su to root, whereas on FreeBSD, the $USER is the same > >as before the su. > > [Line wrap at 72, please] > > Excerpt from su(1): > --- > By default, the environment is unmodified with the exception of USER, > HOME, and SHELL. HOME and SHELL are set to the target login's default > values. USER is set to the target login, unless the target login has a > user ID of 0, in which case it is unmodified. The invoked shell is the > target login's. This is the traditional behavior of su. > > -l Simulate a full login. > --- > > You are observing none other than the expected behavior. I have never > seen Linux (GNU) su do things any differently in this regard. If they > do, it's broken. > > Brandon D. Valentine > -- > "Iam mens praetrepidans avet vagari." > - G. Valerius Catullus, Carmina, XLVI > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message msg30202/pgp0.pgp Description: PGP signature
Re: aps2file doesn't work on FreeBSD
Anthony Schneider wrote: > Linux: > > anthony:/home/anthony:9% uname -a > Linux lappy.slc.edu 2.2.17-21mdk #1 Thu Oct 5 13:16:08 CEST 2000 i686 unknown > anthony:/home/anthony:10% su > Password: > [root@lappy anthony]# echo $USER > root > [root@lappy anthony]# exit > anthony:/home/anthony:11% su -l > Password: > [root@lappy /root]# echo $USER > root > [root@lappy /root]# It may work on Linux that way but you are supposed to do a "su -" on FreeBSD. For example, opal:kent> su Password: opal# env USER=kent opal:kent> su - Password: USER=root The system knows the difference. Kent > > > FreeBSD: > > anthony:/home/anthony:20% uname -a > FreeBSD flack.slc.edu 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT >2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 > anthony:/home/anthony:21% su > Password: > flack# echo $USER > anthony > flack# exit > anthony:/home/anthony:22% su -l > Password: > flack# echo $USER > root > flack# logout > anthony:/home/anthony:23% > > From 'info su' on my linux box: > >By default, `su' does not change the current directory. It sets the > environment variables `HOME' and `SHELL' from the password entry for > USER, and if USER is not the super-user, sets `USER' and `LOGNAME' to > USER. By default, the shell is not a login shell. > > su version (on my linux box): > > [root@lappy anthony]# su --version > su (GNU sh-utils) 2.0 > Written by David MacKenzie. > > Copyright (C) 1999 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > [root@lappy anthony]# > > Perhaps it's time to contact gnu? > > -Anthony. > > [ and apologies for the line wrapping ] > > On Mon, Dec 17, 2001 at 03:09:19AM -0500, Brandon D. Valentine wrote: > >>On Sun, 16 Dec 2001, Anthony Schneider wrote: >> >> >>>Well, the reason I brought up $USER inheritance is that on linux, $USER >>>is root after an su to root, whereas on FreeBSD, the $USER is the same >>>as before the su. >>> >>[Line wrap at 72, please] >> >>Excerpt from su(1): >>--- >>By default, the environment is unmodified with the exception of USER, >>HOME, and SHELL. HOME and SHELL are set to the target login's default >>values. USER is set to the target login, unless the target login has a >>user ID of 0, in which case it is unmodified. The invoked shell is the >>target login's. This is the traditional behavior of su. >> >>-l Simulate a full login. >>--- >> >>You are observing none other than the expected behavior. I have never >>seen Linux (GNU) su do things any differently in this regard. If they >>do, it's broken. >> >>Brandon D. Valentine >>-- >>"Iam mens praetrepidans avet vagari." >>- G. Valerius Catullus, Carmina, XLVI >> >> >>To Unsubscribe: send mail to [EMAIL PROTECTED] >>with "unsubscribe freebsd-hackers" in the body of the message >> > -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://users.owt.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Caldera and the Ancient UNIX license
Peter Jeremy wrote: > I'm specifically looking at 2.11BSD - which is architecturally UFS but > various sizes and constants are different (eg fewer direct/indirect > blocks in the inode). In some ways this simplifies things (it may be > possible to re-use much or all of the FreeBSD UFS code) but it also > confuses things (eg having two different struct dinode's defined, and > there will probably be be global variable/function name clashes). >From memory, use of negative numbers to indicate indirect blocks and thus double the fields was also a recent addition by BSD 4.x. > In any case, I'm more interested in how to go about porting a new FS > into FreeBSD, rather than having Terry actually do the port for me. I'll write it up as the result of doing a port. I'd prefer something non-trivial. I could do BFS fairly easily, right now, since I have some disk images of BFS disks, and some SCO documentation. The SCO documentation on the S51K is not online since the Caldera takeover, it seems, though I have a number of installation disks for drivers for Interactive UNIX that I could use for the reference. The JFS is annoying, in that the minimal image size is 16M for a FS, since this is the smallest partition container for an aggregate, but it is also a possibility (though I will not be pulling down 16M disk images over my modem, and the need to run a local JFS, and thus risk claims of contamination is too great to cause me to pursue it now). The Trade Secret areguments are moot, for independent developement, or for redisclosure of a disclosure, though illegal, which was already made public (in fact, it is a First Ammendement right, which may be abbridged only by as a result of dire National Security interests, according to a recent Apellate Court ruling in the DeCSS case). The BSD 2.x UFS is attractive because it would be useful, as well as being close to another FS, and having (almost) the right license. I would be interested to know how it stacks up against the Net/1 and Net/2 UFS distributions (Net/2 was withdrawn by UCB as part of the USL/UCB settlement, but is still legally available elsewhere). > Last time I tried, I could mount a Tru64 UFS CD-ROM on FreeBSD, but > the box would panic fairly quickly when I tried to access the FS (I > didn't keep a close record and this was some time ago). This has potential, if you can physically give me a copy of a CDROM with one of these FS's on it, and some idea of the layout from an academic or other published source (for the purposes of reverse engineering, header files are considered published sources, for the most part, but check your license -- not the notice in the header files -- to be sure. Compaq has been rather more cooperative, in any case. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aps2file doesn't work on FreeBSD
Anthony Schneider wrote: > > Well, the reason I brought up $USER inheritance is that on linux, $USER is root > after an su to root, whereas on FreeBSD, the $USER is the same as before the su. > Not really thinking, I thought that perhaps that refleted the inherited $UID, > which I was wrong about. Sorry for that. This is broken in Linux. USER is the login user name, which is invariant over "su", according to POSIX. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Q regarding booting from Mylex acceleraid170
Originally posted to questions- with no answer, maybe someone here can help? cheers Andy -Original Message- Sent: 12 December 2001 15:38 To: [EMAIL PROTECTED] Subject: Q regarding booting from Mylex acceleraid170 Hi All I have a Dell Poweredge 2550 with on board SCSI 7899 controller. That controller is not actually fitted to any drives, only the tape unit (DDS3). I actually have a Mylex Acceleraid170 board attached to the four Scsi drives creating a single drive volume. All seems to work fine but the boot up is painfully slow, for example:- /kernel: acd0: CDROM at ata0-master using PIO4 /kernel: Waiting 3 seconds for SCSI devices to settle [Wait 2.5 minutes here, then] /kernel: mly0: physical device 0:6 sense data received /kernel: mly0: sense key 5 asc 00 ascq 00 /kernel: mly0: info csi [Wait a further 3 minutes here, then] /kernel: mly0: enclosure 6 unit 0 access offline Mounting root from ufs:/dev/da0s1a [Wait a further 2 minutes here then] /kernel: da0 at mly0 bus 1 target 0 lun 0 /kernel: da0: Fixed Direct Access SCSI-3 device /kernel: da0: 135.168MB/s transfers /kernel: da0: 34688MB (71041024 512 byte sectors: 255H 63S/T 4422C) [booting continues normally from here] Anyone any idea why this is all so slow? Not complaining too much since it works but I can't help thinking I've done something wrong because of this. fyi I'm running 4-STABLE [as of 12/12/2001] and it happens with both GENERIC and my custom kernel. Before going to STABLE I installed R4.3 from CDRom and it did the same there also (GENERIC and custom). cheers Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
What a FBSD FS needs to do?
Can anyone give a brief overview (or point to one) of what a FS in FreeBSD needs to do to interact with the rest of the OS? The general picture I've got is of some code which interacts with the VFS layer above it and the block I/O layer down below it. It is this correct? And what are the APIs in those layers? (and how does the FS interact with the VM?) (I actually plan on sitting down and reading the FFS sources at some point in the near future and seeing if I can learn that way, but any help would be appreciated...) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Tony wrote: > 1. "JFS only operates on meta-data ... It does not log file data or > recover this data to a consistent state." [JFS overview] Yes. > "The logging style introduces a synchronous write to the log disk > into each inode or vfs operation that modifies meta-data." [JFS > overview] This is actually only for small directories an immediate metadata; most operations are in facted journalled, instead. Realize also that, though it doesn't do it, the synchronicity is once again an issue of ordered writes... so Soft Updates could be applied here. > This doesn't sound any more robust than FreeBSD's current > Softupdates. JFS wins though as fsck is faster on a reboot ... They actually discuss the failure modes for JFS, which include most reasons you would need to run an fsck. For a relatively quiescent system, the consistancy will be restored via journal pass, but if the journal consistency is bad, then it will do a full fsck. So it is likely to be necessary on IDE disks, which can spam sectors when writing during a power loss (things would be better un SCSI). Note that one of the reasons for the DC holdup time on the InterJet was to ensure the drive write cache was flushed, so that the drive was quiescent -- not in the middle of a write operation -- when DC finally failed. > Does AIX JFS log any file data? Yes (or ratherm, it journals it). And the EXT3 FS and BSD LFS do the same, and so do XFS and VxFS, though the last two do lazy synchronization. > 2. "The minimum file system size supported by JFS is 16Mbytes." [JFS > overview] Yeah, annoying, that. > "JFS will not support diskettes as an underlying file system." [JFS > overview] Just a size thing. > I believe AIX JFS does support diskettes / removable media. Yes, it does. > 3. Linux JFS does not support AIX JFS volumes. [various places] > > I am not clear whether this is inherent in some data structures > being different, or just that Linux doesn't process LVM info. This is AIX JFS vs OS/2 JFS. There would also be byte order issues, since the PPX running AIX operates in Motorolla byte order (network byte order), and not Intel byte order (wrong byte order 8^)). > JFS on AIX is "backward compatible" with Enhanced JFS (JFS2). JFS2 on AIX supports OS/2 JFS. > 4. The Linux JFS driver is noticeably incomplete [from JFS todo list]: > o SMP bugs. A given. They would need to introduce synchronization points in their SMP to address this. Linux SMP has similar problems in most code requiring ordered operations. > o Only 4096 byte block sizes currently supported. >(512, 1024 and 2048 should be available too.) It's a page granularity issue, due to explicit cache coherency requirements for an incompletely unified VM and buffer cache implementation. Going to the Intelk page size for the block size was an easy cop-out on the coherency update issues. > o No defrag tool. Actually, I saw one of these. You need to read the more detailed information, and not just the overview. > o FS resizing is not yet available. It can grow them, up to the size of the aggregate. The problem is that the LVM support for PP spanning (aggregating aggregates) is not there. Also, since they currently onbly permit a single aggregate set per partition, you tend to carve up your disks with no space to spare. In contrast, on OS/2 (or AIX, in the absence of LVM and/or disk spanning for lack of additional disks), you can have multiple aggregate sets per, so you usually end up with the whole disk being given over to a single monolithic block with multiple aggregate sets (one per FS). So I think this is just an artifact on the grow, and the lack of a defragmenter on a shrink (see above, about the defragger). > o Log file must be on the JFS partition. Not really a problem. > o Disk quotas are not currently supported. On FreeBSD, quotas should be implemented as a stacking layer with namespace folding anyway. I look at this one as "incentive". > o Extended Attributes and Access Control Lists are not functional. Actually file streams are not functional, which is not the same thing. > 5. "JFS is still guru-friendly (meaning that you need a Linux guru on > hand), but it will eventually grow into administrator-friendly." > [JFS FAQ] > > I'm not sure what this means, possibly just that the FS utilities > and man pages need some work. It means default installation using a RedHat or other Linux CDROM. > Undoubtedly JFS on FreeBSD would be expected to work with Linux JFS > volumes, but inter-operation with AIX JFS & JFS2 is also desirable. AIX JFS2 is achievable. AIX JFS is not, with that code, since it is a subset of the AIX JFS functionality, to begin with. > My questions at this point are: > * is there any IBM material, white papers or whatever, that I could >study to find out about JFS(2) on AIX? There are severa
Re: A quick VM question
Zhihui Zhang wrote: > What are the backing objects of the stack and heap area of a process's > address space? When are they created? I saw the code vm_map_insert(), but > the object argument given is NULL. Anonymous pages: swap. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sha1 program
On Sun, Dec 16, 2001 at 01:57:44PM +1030, Daniel O'Connor wrote: > > On 15-Dec-2001 Kris Kennaway wrote: > > Or just ln -sf /usr/bin/openssl /usr/bin/sha1 > > > > OpenSSL already checks the name it's invoked under and behaves > > accordingly. > > Does it grok the options for md5? :) > -s would be easy to simulate in a shell script. > -p would be much more difficult unless openssl supports it. I have no idea off-hand what flags it supports, but I'd expect it to not be completely downwards-compatible. The OpenSSL folks might be interested in patches though. Kris msg30210/pgp0.pgp Description: PGP signature
deadlock with softupdates ?
We have a newserver running here, which freezes every 2-3 days. Break into db is still possible. It is a STABLE 4.4 machine, with new kernel. NEWS # mount /dev/da0s1a on / (ufs, local, soft-updates) /dev/da0s1e on /var (ufs, local, soft-updates) /dev/da1s1e on /news (ufs, local, soft-updates) /dev/da2s1e on /news/spool/overview (ufs, local, soft-updates) procfs on /proc (procfs, local) /dev/twed0s1e on /news/spool/articles/1 (ufs, local, soft-updates) /dev/twed1s1e on /news/spool/articles/2 (ufs, local, soft-updates) The latter two filesystems have 10 big files with the cyclic news filesystem on them. So we have a filesystem on a filesystem. I guess this is what makes the problems. I've got a kernel dump of a hanged session, but it is not very informative. bash-2.05a# ps -M /var/crash/vmcore.0 -N /usr/src/sys/compile/NEWS/kernel.deb-axl | more UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 8 289 1 100 10 0 6680 wait IW #C5- 0:00.00 (sh) 8 290 1 100 10 0 6680 wait IW #C5- 0:00.00 (sh) 8 292 289 0 -18 0 6800 vmwait DL #C5- 0:30.78 (sh) 8 293 290 0 -14 0 36440 inode D#C5- 0:49.73 (perl) 0 12263 1 0 10 0 12000 wait IWs #C50:00.00 (login) 0 12295 12263 0 18 0 13240 pause IW #C50:00.00 (csh) 0 12297 12295 0 10 0 10600 wait IW #C50:00.00 (bash) 0 12300 12297 0 -5 0 15320 sysctl D+ #C56:58.09 (systat) 1042 677 671 0 18 0 5800 pause IWs #C50:00.00 (ksh) 0 689 677 0 18 0 13360 pause IW #C50:00.00 (csh) 0 696 689 0 18 0 5880 pause I#C50:00.03 (ksh) 8 13284 696 12 10 0 6320 wait I#C50:00.01 (sh) 8 13742 13284 12 10 0 6360 wait I+ #C50:00.01 (sh) 8 13750 13742 0 -18 0 1729600 vmwait DL+ #C50:01.82 (suck) 0 317 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 316 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 315 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 314 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 313 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 312 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 319 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 318 1 0 3 0 9480 ttyin IWs+ #C10:00.00 (getty) 0 12307 12306 0 10 0 10640 wait IWs #C90:00.00 (bash) 0 12312 12307 0 10 0 10640 wait IW #C90:00.00 (bash) 0 12313 12312 0 -18 0 20120 vmwait D+ #C98:22.42 (top) 0 59816 59812 0 3 0 10640 ttyin Is+ #C60:00.04 (bash) 1042 35037 35035 2 18 0 5800 pause IWs #C60:00.00 (ksh) 0 35050 35037 0 18 0 13360 pause IW #C60:00.00 (csh) 0 35059 35050 0 3 0 6000 ttyin I+ #C60:00.17 (ksh) 0 0 0 0 -18 0 00 sched DLs ??0:00.00 (swapper) 0 1 0 0 10 0 5440 wait ILs ??0:00.01 (init) 0 2 0 0 -14 0 00 inode DL??0:36.22 (pagedaemon 0 3 0 38 18 0 00 psleep DL??0:00.61 (vmdaemon) 0 4 0 0 -18 0 00 psleep DL??0:43.03 (bufdaemon) 0 5 0 0 18 0 00 syncer DL?? 10:42.21 (syncer) 0 137 1 0 -18 0 24040 vmwait DLs ??0:54.90 (gated) 0 149 1 0 2 0 9600 select Ss??3:42.56 (syslogd) 0 158 1 0 2 -12 12720 select S: mov0x141(%ebx),%al frame 1 at 0xd78bdc34: ebp d78bdc50, eip 0xc0238897 : add$0x10,%esp frame 2 at 0xd78bdc50: ebp d78bdd00, eip 0xc0230574 : add$0x8,%esp frame 3 at 0xd78bdd00: ebp d78bdd28, eip 0xc0284b9e : mov%eax,%ecx frame 4 at 0xd78bdd28: ebp d78bdd6c, eip 0xc02847af : jmp0xc0284afe frame 5 at 0xd78bdd6c: ebp d78bdde4, eip 0xc0276730 : push %ebx frame 6 at 0xd78bdde4: ebp d78bde48, eip 0xc0226dbe : mov%eax,0xffd4(%ebp) frame 7 at 0xd78bde48: ebp d78bde7c, eip 0xc01aba18 : mov%eax,0xffe8(%ebp) frame 8 at 0xd78bde7c: ebp d78bdef8, eip 0xc0185cc0 : mov%eax,%esi frame 9 at 0xd78bdef8: ebp d78bdf2c, eip 0xc0185b86 : mov %eax,%esi frame 10 at 0xd78bdf2c: ebp d78bdfa0, eip 0xc028520d : mov%eax,0xffb8(%ebp) (kgdb) defproc 13750 13750 d78cd0c0 d7b9b0008 13742 13742 804006 3 suck vmwait c031f718 frame 0 at 0xd7b9dc08: ebp d7b9dc34, eip 0xc017a529 : mov0x141(%ebx),%al frame 1 at 0xd7b9dc34: ebp d7b9dc50, eip 0xc0238897 : add$0x10,%esp frame 2 at 0xd7b9dc50: ebp d7b9dd00, eip 0xc0230574 : add$0x8,%esp frame 3 at 0xd7b9dd00: ebp d7b9dd28, eip 0xc0284b9e : mov%eax,%ecx frame 4 at 0xd7b9dd28: ebp d7b9dd6c, eip 0xc02847af : jmp
Conference calls are safe
Title: Take Control Of Your Conference Calls Long Distance ConferencingOnly 18 Cents Per Minute Connects Up To 100 Participants! No setup fees No contracts or monthly fees Call anytime, from anywhere, to anywhere International Dial In 18 cents per minute Simplicity in set up and administration Operator Help available 24/7 Get the best quality, the easiest to use, and lowest rate in the industry. If you like saving money, fill out the form below and one of our consultants will contact you. Required Input Field* Name* Web Address* Company Name* State* Business Phone* Home Phone Email Address* Type of Business This ad is being sent in compliance with Senate Bill 1618, Title 3, Section 301. You have recently visited our web site, referral or affiliate sites which indicated you were interested in communication services. If this email is reaching you in error and you feel that you have not contacted us, Click here. We sincerely apologize, and assure you will be removed from our distribution list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What a FBSD FS needs to do?
Lamont Granquist wrote: > > Can anyone give a brief overview (or point to one) of what a FS in FreeBSD > needs to do to interact with the rest of the OS? The general picture I've > got is of some code which interacts with the VFS layer above it and the > block I/O layer down below it. It is this correct? And what are the APIs > in those layers? (and how does the FS interact with the VM?) Briefly, there are ~185 kernel entry points which are consumed by the FFS code. To see these, go into the directory were you build your kernel and have object files lying around, and conunt them, e.g.: # cd /sys/compile/GENERIC # sh # ld -o /tmp/ffsobj ffs* ufs* >/tmp/ffs.link 2>&1 # cd /tmp # vi ffs.link :1,$g/:$/d :1,$g/more undefined/d :1,$s/'$// :1,$s/^.*`// :x # sort -o ffs.sort < ffs.link # uniq < ffs.sort > ffs.uniq # wc -l ffs.uniq 185 I have attached an example of the result, for my older 4.x based system to this email. If you look at these, you will see 5 broad categories: 1) Kernel support services. These are things like bzero, copyin, printf, uiomove, timeout, tsleepm untimeout, etc., and are required support functions that aren't really FS specific. Another OS would call then "generic kernel services", but wouldn't have the whole story. 2) VFS services. These are things like vfs_add_vnops, vfs_export, vfs_timestamp, etc., and are required for registration and recognition of the FS as a VFS. There are also services for manipulation of VFS specific kernel resources in this category. 3) Vnode services. These are things like all of the vop_* operations, vget, vgone, NDFREE, and so on. These services services represent both VFS service, which the VFS can call for stacking reasons (it calls these services, rather than calling the VFS specific routines it defines in orcer to abstract the VFS so that you can do VFS stacking, and things won't break), and VFS specific resource that are managed by the OS (such as vnodes, etc.). Note: The NDFREE reference is actually an implemenation error, since it breaks the "caller allocates/caller frees" paradigm; this is a long-standing layering issue. 4) Virtual memory and I/O services. These are things like malloc, free, cache_enter, getblk, bread, vm_object_deallocate, vinvalbuf, etc.. These services represent the VFS' interaction with the VM system, and, as a result, the buffer cache. The spl* functions, which are used for concurrency control, as well as the locking primitives, fall into this category. It's important to note that most of these operations only exist in "local media" FSs... if your VFS were implementing a stacking layer, you would not have almost any of these used by it, since the services consumed would be pretty much covered in #3, above. 5) Miscellaneous functions. Into this category, I lump all the inconvenient to explain functions, like the spec_* functions, which implement the special device operations exported by the VFS (when you look up a device, you actually get a specfs vnode back, instead of an FFS vinode, but since the backing object is an FFS object, you have to reference it through the FFS), and, similarly, the fifo_* operations (which are used to manage named pipes -- FIFO objects -- in the same way. You would also see "__divdi3" here, as well as other systhetic functions which are, in reality, an artifact of the compiler. Practically, nearly half of these undefined symbols could be made to go away, with little to no effect on performance. In particular, the descriptor references could be factored out at FS instance time, when the mount takes place, and a stack is "frozen" as a mounted FS instance. The way you would do this is to sort the VOP and VFSOP lists, respectively, and then build direct references, rather than descriptor references, and access them by index, rather than descirptor (this would be slightly faster, too). Other references could additionally be eliminated, as they are really the result of sloppy references (e.g. the spec_* and fifo_* entries: the first by mount-based externalization and inheritance, and the seconfd by pure inheritance, enforced at instance time). A lot of the b* buffer cache operations should probably be via an ops structure dereference; this means an additional pointer dereference at runtime, so some of the wins you got by sorting the VOP list and using an index, insteaqd of areverse lookup of the descriptor reference, get paid back at that time, but overall you are still better off. Ig you have ever programmed an IFS under Windows, you
Fwd: [Re: DELACK bugfix: This tbench is giving me a fit]
Hi, All. A couple of friends are testing my DELACK backport, and their initial run (pre-patch) of 'tbench' is, well, outrageous. My numbers weren't anywhere near this bad. Their boxes are functional, "production" boxes, one is 4.3R and the other is 4.4S. Their hardware is [relatively] current; certainly not ancient. I queried as to whether they remembered to start 'tbench_srv'; one replied affirmative, the other hasn't gotten back to me on that. I supplied instructions to them both, and they're not dummies, so I'm confident they did. The tests are on 127.1, so NIC and network media shouldn't matter. As John asks, then, WTF??? TIA, Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ - Forwarded message from a friend of mine - It is taking over 90 minutes to run, take a look at the attached log. What am I forgetting to do? John [router:/usr/local/src/dbench]# time ./tbench 1 localhost .1 clients started ..+* Throughput 0.0242604 MB/sec (NB=0.0303256 MB/sec 0.242604 MBit/sec) 5441.96s real 1.20s user 2.16s system - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: deadlock with softupdates ?
On 17-Dec-01 Martin Blapp wrote: > > We have a newserver running here, which freezes > every 2-3 days. Break into db is still possible. > > It is a STABLE 4.4 machine, with new kernel. > > NEWS # mount > /dev/da0s1a on / (ufs, local, soft-updates) > /dev/da0s1e on /var (ufs, local, soft-updates) > /dev/da1s1e on /news (ufs, local, soft-updates) > /dev/da2s1e on /news/spool/overview (ufs, local, soft-updates) > procfs on /proc (procfs, local) > /dev/twed0s1e on /news/spool/articles/1 (ufs, local, soft-updates) > /dev/twed1s1e on /news/spool/articles/2 (ufs, local, soft-updates) > > The latter two filesystems have 10 big files with the cyclic news > filesystem on them. So we have a filesystem on a filesystem. You have lots of processes blocked in 'inode'. So it looks like it could be an inode deadlock problem. You might try mailing Kirk McKusick directly if he doesn't respond to this. Be sure and keep the debug kernel and crashdump image around. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
I'm trying to get the license issue clarified, then it can go in /usr/src/tools/regression. - Jordan > Jordan Hubbard <[EMAIL PROTECTED]> writes: > > > Guy Harris of NetApp sent me a whole mess-o-changes to it and when I > > went to forward them to you, I found that I must have been in > > delete-o-matic mode at some point earlier in my inbox since it was > > gone. I've requested that he send them to me again and will forward > > them to you once I get a copy again. Whoops! > > Would it be worth making a port for this tool? It sounds like it's > too important to get lost in a mailing list archive. There's a > precedence set by having /usr/ports/sysutils/crashme. :-) > > -Dom > > -- > | Semantico: creators of major online resources | > | URL: http://www.semantico.com/ | > | Tel: +44 (1273) 72 | > | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
> > This doesn't sound any more robust than FreeBSD's current > > Softupdates. JFS wins though as fsck is faster on a reboot ... Please correct me if I'm wrong. But I heard that Kirk (or perhaps someone else) is continuing softupdates development with the intent of removing any dependency for fsck. > > Does AIX JFS log any file data? > > Yes (or ratherm, it journals it). And the EXT3 FS and BSD LFS do the > same, and so do XFS and VxFS, though the last two do lazy synchronization. Actually, for the record, XFS only logs file metadata. > > * where is a good place to start learning about FreeBSD file systems, > >specifically UFS? Well, if you have a copy of the "Daemon Book", chapters 6 - 8 would probably be a good place to start. Also, for geneneral FS design I highly recommend Dominic Giampaolo's book "Practical File System Design". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Q regarding booting from Mylex acceleraid170
> I have a Dell Poweredge 2550 with on board SCSI 7899 controller. > That controller is not actually fitted to any drives, only the > tape unit (DDS3). > > I actually have a Mylex Acceleraid170 board attached to the four > Scsi drives creating a single drive volume. All seems to work fine > but the boot up is painfully slow, for example:- This looks like an incompatibility between the Mylex firmware and the intelligent backplane in the server: > /kernel: mly0: physical device 0:6 sense data received > /kernel: mly0: sense key 5 asc 00 ascq 00 > /kernel: mly0: info csi This is the Mylex card being unhappy about the backplane... > [Wait a further 3 minutes here, then] > > /kernel: mly0: enclosure 6 unit 0 access offline And here it finally gives up on it. > Anyone any idea why this is all so slow? Not complaining too > much since it works but I can't help thinking I've done something > wrong because of this. It's an incompatibility between the backplane and the Mylex controller. You might try looking for firmware upgrades from Dell or Mylex, but realistically Dell use Adaptec and AMI controllers and they aren't likely to support your use of another vendor's controllers in their hardware. Mylex technical support might have something to say on the subject, although the results you'll get will vary enormously depending on which tech you get and whether they're a Linux bigot or not. Your best alternative would be to swap to a comparable AMI controller, something like a MegaRAID Express 500. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
: :We have a newserver running here, which freezes :every 2-3 days. Break into db is still possible. : :It is a STABLE 4.4 machine, with new kernel. Yahoo noticed a deadlock in the vnode recycling code. If your machine below is hitting the kern.maxvnodes limit it could be the same thing. The way to tell is to generate a kernel core along with the debug version of the kernel binary (/usr/src/sys/compile//kernel.debug), and backtrace each locked-up process to see if any of them are going through the recycle code. Yahoo has a fix for that particular problem that they and I are testing. -Matt :NEWS # mount :/dev/da0s1a on / (ufs, local, soft-updates) :/dev/da0s1e on /var (ufs, local, soft-updates) :/dev/da1s1e on /news (ufs, local, soft-updates) :/dev/da2s1e on /news/spool/overview (ufs, local, soft-updates) :procfs on /proc (procfs, local) :/dev/twed0s1e on /news/spool/articles/1 (ufs, local, soft-updates) :/dev/twed1s1e on /news/spool/articles/2 (ufs, local, soft-updates) : :The latter two filesystems have 10 big files with the cyclic news :filesystem on them. So we have a filesystem on a filesystem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding a new FS to FreeBSD
If it's just for the exercise of porting a filesystem, there are at least three filesystems available under a BSD license: 1) Minix: all the OS was released under a BSD like license, not to mention that it is perfectly documented. 2,3) NetBSD's ext2fs and LFS have surely been updated for their UBC effort. These probably wouldn't have any advantage over FFS though. If someone has a wishlist it would be nice to be able to mount the FFS variant's, not only Tru64 UFS, but especifically Solaris. Now that a SPARC64 port is coming it would be really handy. just my $0.02, Pedro. __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
Hi Matt, > Yahoo noticed a deadlock in the vnode recycling code. If your machine > below is hitting the kern.maxvnodes limit it could be the same thing. > The way to tell is to generate a kernel core along with the debug > version of the kernel binary (/usr/src/sys/compile//kernel.debug), > and backtrace each locked-up process to see if any of them are going > through the recycle code. It cannot be kern.maxvnodes, cause the newsserver is using the cyclic news filesystem. And there is also enough ram. It seems to be a vnode deadlock: (kgdb) defproc 2 2 d78cd0c0 d64450000 0 0 100204 3 pagedaemon inode c2c0c200 frame 0 at 0xd6447e24: ebp d6447e50, eip 0xc017a529 : mov 0x141(%ebx),%al frame 1 at 0xd6447e50: ebp d6447e74, eip 0xc0171c24 : mov %eax,%esi frame 2 at 0xd6447e74: ebp d6447e98, eip 0xc0171ea5 : mov %eax,%edi frame 3 at 0xd6447e98: ebp d6447eb0, eip 0xc01a2008 : jmp 0xc01a200e frame 4 at 0xd6447eb0: ebp d6447ebc, eip 0xc022e44d : leave frame 5 at 0xd6447ebc: ebp d6447ee4, eip 0xc01ac04b : add $0x4,%esp frame 6 at 0xd6447ee4: ebp d6447f00, eip 0xc01a4e18 :mov %eax,%esi frame 7 at 0xd6447f00: ebp d6447f84, eip 0xc023a52d : add $0xc,%esp frame 8 at 0xd6447f84: ebp d6447f9c, eip 0xc023af53 :movl $0x0,0xc02eff1c (kgdb) x/x 0xd6447f00 0xd6447f00: 0xd6447f84 (kgdb) x/10 0xd6447f00 0xd6447f00: 0xd6447f84 0xc023a52d 0xd7e5a180 0x00040002 0xd6447f10: 0xd47c2c60 0x 0x 0x 0xd6447f20: 0xd7e5a180 0x0020 (kgdb) showcache 0xd7e5a180 history.hash Can you help me to debug this bug ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
If it is a vnode deadlock you have to find which process or processes it is deadlocking against. Do a ps -axl -M vmcore.X -N kernel.X on the kernel core, pick out all the processes blocked on inode or whatever, then from gdb go to each process (proc N) and do a backtrace (back). -Matt Matthew Dillon <[EMAIL PROTECTED]> : : :Hi Matt, : :> Yahoo noticed a deadlock in the vnode recycling code. If your machine :> below is hitting the kern.maxvnodes limit it could be the same thing. :> The way to tell is to generate a kernel core along with the debug :> version of the kernel binary (/usr/src/sys/compile//kernel.debug), :> and backtrace each locked-up process to see if any of them are going :> through the recycle code. : :It cannot be kern.maxvnodes, cause the newsserver is using the cyclic :news filesystem. And there is also enough ram. : :It seems to be a vnode deadlock: : :(kgdb) defproc 2 :2 d78cd0c0 d64450000 0 0 100204 3 pagedaemon inode c2c0c200 : frame 0 at 0xd6447e24: ebp d6447e50, eip 0xc017a529 : mov :0x141(%ebx),%al : frame 1 at 0xd6447e50: ebp d6447e74, eip 0xc0171c24 : mov :%eax,%esi : frame 2 at 0xd6447e74: ebp d6447e98, eip 0xc0171ea5 : mov :%eax,%edi : frame 3 at 0xd6447e98: ebp d6447eb0, eip 0xc01a2008 : jmp :0xc01a200e : frame 4 at 0xd6447eb0: ebp d6447ebc, eip 0xc022e44d : leave : frame 5 at 0xd6447ebc: ebp d6447ee4, eip 0xc01ac04b : add :$0x4,%esp : frame 6 at 0xd6447ee4: ebp d6447f00, eip 0xc01a4e18 :mov :%eax,%esi : frame 7 at 0xd6447f00: ebp d6447f84, eip 0xc023a52d : add : $0xc,%esp : frame 8 at 0xd6447f84: ebp d6447f9c, eip 0xc023af53 :movl : $0x0,0xc02eff1c : :(kgdb) x/x 0xd6447f00 :0xd6447f00: 0xd6447f84 :(kgdb) x/10 0xd6447f00 :0xd6447f00: 0xd6447f84 0xc023a52d 0xd7e5a180 0x00040002 :0xd6447f10: 0xd47c2c60 0x 0x 0x :0xd6447f20: 0xd7e5a180 0x0020 :(kgdb) showcache 0xd7e5a180 :history.hash : :Can you help me to debug this bug ? : :Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
At 12:24 PM -0800 12/16/01, Matthew Dillon wrote:
>program runs fine in an overnight test. We still have a known issue
>with out-of-order operations from nfsiod's that apparently may come
>up after a week or so of testing. I asked Jordan to try to track down
>the NeXT guy who fixed that one in the old NFS stack.
This bug showed up recently here with fsx testing. I seem to have fixed it
last week in MacOS X. The diffs were widespread but the idea was simple
enough so a few code snippets should suffice:
nfs_request gets a new argument (u_int64_t *xidp) and fills it in here:
m = nfsm_rpchead(cred, nmp->nm_flag, procnum, auth_type, auth_len,
auth_str, verf_len, verf_str, mrest, mrest_len, &mheadend, &xid);
if (xidp)
*xidp = xid + ((u_int64_t)nfs_xidwrap << 32);
nfsm_rpchead bumps nfs_xidwrap when avoiding a zero xid.
Callers of nfs_request take the returned xid and pass it via the macros to
nfs_loadattrcache, from which the following code is snipped:
if (*xidp < np->n_xid) {
/*
* We have already updated attributes with a response from
* a later request. The attributes we have here are probably
* stale so we drop them (just return). However, our
* out-of-order receipt could be correct - if the requests were
* processed out of order at the server. Given the uncertainty
* we invalidate our cached attributes. *xidp is zeroed here
* to indicate the attributes were dropped - only getattr
* cares - it needs to retry the rpc.
*/
np->n_attrstamp = 0;
*xidp = 0;
return (0);
}
Further down in nfs_loadattrcache:
np->n_xid = *xidp;
Note xids are kept in a 64 bit form so relative comparison won't fail in
the unlikely case that xids wrap around zero.
Here's the change in nfs_getattr. I don't expect to ever see the panic.
avoidfloods = 0;
tryagain:
nfsstats.rpccnt[NFSPROC_GETATTR]++;
nfsm_reqhead(vp, NFSPROC_GETATTR, NFSX_FH(v3));
nfsm_fhtom(vp, v3);
nfsm_request(vp, NFSPROC_GETATTR, ap->a_p, ap->a_cred, &xid);
if (!error) {
nfsm_loadattr(vp, ap->a_vap, &xid);
if (!xid) { /* out-of-order rpc - attributes were dropped */
m_freem(mrep);
if (avoidfloods++ < 100)
goto tryagain;
/*
* avoidfloods>1 is bizarre. at 100 pull the plug
*/
panic("nfs_getattr: getattr flood\n");
}
--
Conrad Minshall, [EMAIL PROTECTED], 408 974-2749
Apple Computer, Mac OS X Core Operating Systems
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
> Do a ps -axl -M vmcore.X -N kernel.X on the kernel core, > pick out all the processes blocked on inode or whatever, inode ps -axl -M vmcore.0 -N /usr/src/sys/compile/NEWS/kernel.debug | grep inode 8 293 290 0 -14 0 36440 inode D#C5- 0:49.73 (perl) 0 2 0 0 -14 0 00 inode DL??0:36.22 (pagedaemon) 8 288 1 0 -14 0 1334200 inode DLs ?? 28:25.45 (innd) 8 13771 288 0 -14 4 20720 inode DN??0:00.01 (nnrpd) 8 13775 288 0 -14 4 21280 inode DN??0:00.01 (nnrpd) 8 13779 288 0 -14 4 21200 inode DN??0:00.01 (nnrpd) 8 13781 288 0 -14 4 459680 inode DN??0:00.01 (nnrpd) > then from gdb go to each process (proc N) and do a backtrace > (back). (kgdb) defproc 288 288 d78cd0c0 d788e0008 1 288 05 3 innd inode c2c0c200 frame 0 at 0xd7890d8c: ebp d7890db8, eip 0xc017a529 : mov 0x141(%ebx),%al frame 1 at 0xd7890db8: ebp d7890ddc, eip 0xc0171c24 : mov %eax,%esi frame 2 at 0xd7890ddc: ebp d7890e00, eip 0xc0171cd4 : mov %eax,%edi frame 3 at 0xd7890e00: ebp d7890e18, eip 0xc01a2008 :jmp 0xc01a200e frame 4 at 0xd7890e18: ebp d7890e24, eip 0xc022e44d : leave frame 5 at 0xd7890e24: ebp d7890e4c, eip 0xc01ac04b :add$0x4,%esp frame 6 at 0xd7890e4c: ebp d7890e68, eip 0xc01a4e18 :mov %eax,%esi frame 7 at 0xd7890e68: ebp d7890e84, eip 0xc023d038 : add $0xc,%esp frame 8 at 0xd7890e84: ebp d7890f34, eip 0xc023060c :mov %eax,0xffbc(%ebp) frame 9 at 0xd7890f34: ebp d7890f5c, eip 0xc0284b9e : mov%eax,% (kgdb) defproc 293 293 d78cd0c0 d78880008 290 6 004006 3 perl inode c1f87400 frame 0 at 0xd788abe8: ebp d788ac14, eip 0xc017a529 : mov 0x141(%ebx),%al frame 1 at 0xd788ac14: ebp d788ac38, eip 0xc0171c24 : mov %eax,%esi frame 2 at 0xd788ac38: ebp d788ac5c, eip 0xc0171e88 : mov %eax,%edi frame 3 at 0xd788ac5c: ebp d788ac74, eip 0xc01a2008 :jmp 0xc01a200e frame 4 at 0xd788ac74: ebp d788ac80, eip 0xc022e44d : leave frame 5 at 0xd788ac80: ebp d788aca8, eip 0xc01ac04b : add $0x4,%esp frame 6 at 0xd788aca8: ebp d788acc4, eip 0xc01a4e18 :mov %eax,%esi frame 7 at 0xd788acc4: ebp d788ace8, eip 0xc02290d4 : add $0xc,%esp frame 8 at 0xd788ace8: ebp d788ad20, eip 0xc02265de : mov 0x10(%ebp),%ecx frame 9 at 0xd788ad20: ebp d788ad38, eip 0xc022b964 : test %eax,%eax frame 10 at 0xd788ad38: ebp d788ad84, eip 0xc01a32b6 : mov %eax,0xffd8(%ebp) frame 11 at 0xd788ad84: ebp d788add8, eip 0xc01a2c74 : mov %eax,%ebx frame 12 at 0xd788add8: ebp d788ae74, eip 0xc01ab45f :mov %eax,%ebx frame 13 at 0xd788ae74: ebp d788af2c, eip 0xc01a7568 : mov %eax,%ebx frame 14 at 0xd788af2c: ebp d788afa0, eip 0xc028520d : mov %eax,0xffb8(%ebp) (kgdb) defproc 13771 13771 d78cd0c0 d7c160008 288 288 004004 3 nnrpdinode c2024b00 frame 0 at 0xd7c18c08: ebp d7c18c34, eip 0xc017a529 : mov 0x141(%ebx),%al frame 1 at 0xd7c18c34: ebp d7c18c58, eip 0xc0171c24 : mov %eax,%esi frame 2 at 0xd7c18c58: ebp d7c18c7c, eip 0xc0171ea5 : mov %eax,%edi frame 3 at 0xd7c18c7c: ebp d7c18c94, eip 0xc01a2008 :jmp 0xc01a200e frame 4 at 0xd7c18c94: ebp d7c18ca0, eip 0xc022e44d : leave frame 5 at 0xd7c18ca0: ebp d7c18cc8, eip 0xc01ac04b : add $0x4,%esp frame 6 at 0xd7c18cc8: ebp d7c18ce4, eip 0xc01a4e18 :mov %eax,%esi frame 7 at 0xd7c18ce4: ebp d7c18d30, eip 0xc01a01b3 :mov %eax,%ebx frame 8 at 0xd7c18d30: ebp d7c18d3c, eip 0xc022e44d : leave frame 9 at 0xd7c18d3c: ebp d7c18d84, eip 0xc01a3179 : mov %eax,0xffd8(%ebp) frame 10 at 0xd7c18d84: ebp d7c18dd8, eip 0xc01a2c74 : mov %eax,%ebx frame 11 at 0xd7c18dd8: ebp d7c18e74, eip 0xc01ab45f :mov %eax,%ebx frame 12 at 0xd7c18e74: ebp d7c18f2c, eip 0xc01a7568 : mov %eax,%ebx frame 13 at 0xd7c18f2c: ebp d7c18fa0, eip 0xc028520d : mov %eax,0xffb8(%ebp) (kgdb) defproc 13775 13775 d78cd0c0 d7b170008 288 288 004004 3 nnrpdinode c1f87400 frame 0 at 0xd7b19c7c: ebp d7b19ca8, eip 0xc017a529 : mov 0x141(%ebx),%al frame 1 at 0xd7b19ca8: ebp d7b19ccc, eip 0xc0171c24 : mov %eax,%esi frame 2 at 0xd7b19ccc: ebp d7b19cf0, eip 0xc0171e88 : mov %eax,%edi frame 3 at 0xd7b19cf0: ebp d7b19d08, eip 0xc01a2008 : jmp 0xc01a200e frame 4 at 0xd7b19d08: ebp d7b19d14, eip 0xc022e44d : leave frame 5 at 0xd7b19d14: ebp d7b19d3c, eip 0xc01ac04b : add $0x4,%esp frame 6 at 0xd7b19d3c: ebp d7b19d58, eip 0xc01a4e18 :mov %eax,%esi frame 7 at 0xd7b19d58: ebp d7b19d7c, eip 0xc02290d4 : add $0xc,%esp frame 8 at 0xd7b19d7c: ebp d7b19db4, eip 0xc02265de : mov 0x10(%ebp),%ecx frame 9 at 0xd7b
Re: deadlock with softupdates ?
:> then from gdb go to each process (proc N) and do a backtrace :> (back). : :(kgdb) defproc 288 : 288 d78cd0c0 d788e0008 1 288 05 3 innd inode :c2c0c200 : frame 0 at 0xd7890d8c: ebp d7890db8, eip 0xc017a529 : mov :0x141(%ebx),%al : frame 1 at 0xd7890db8: ebp d7890ddc, eip 0xc0171c24 : mov :%eax,%esi : frame 2 at 0xd7890ddc: ebp d7890e00, eip 0xc0171cd4 : mov :%eax,%edi : frame 3 at 0xd7890e00: ebp d7890e18, eip 0xc01a2008 :jmp : 0xc01a200e : frame 4 at 0xd7890e18: ebp d7890e24, eip 0xc022e44d : leave : frame 5 at 0xd7890e24: ebp d7890e4c, eip 0xc01ac04b :add :$0x4,%esp : frame 6 at 0xd7890e4c: ebp d7890e68, eip 0xc01a4e18 :mov :%eax,%esi : frame 7 at 0xd7890e68: ebp d7890e84, eip 0xc023d038 : add :$0xc,%esp : frame 8 at 0xd7890e84: ebp d7890f34, eip 0xc023060c :mov :%eax,0xffbc(%ebp) : frame 9 at 0xd7890f34: ebp d7890f5c, eip 0xc0284b9e : mov%eax,% Are you sure this is the correct kernel binary? zinitna() doesn't call vget() and vm_fault doesn't call zinitna. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
Hi Matt, > Are you sure this is the correct kernel binary? zinitna() doesn't > call vget() and vm_fault doesn't call zinitna. Hrm, sorry, I just have noted that the debug kernel produces slightly different output that the normal kernel :-( Why this ? I didn't do a cvs update since I built the kernel. (kgdb) proc 293 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171e88 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc02290d4 in ufs_ihashget () #9 0xc02265de in ffs_vget () #10 0xc022b964 in ufs_root () #11 0xc01a32b6 in lookup () #12 0xc01a2c74 in namei () #13 0xc01ab45f in vn_open () #14 0xc01a7568 in open () #15 0xc028520d in syscall2 () #16 0xc02767b5 in Xint0x80_syscall () #17 0x48082c6f in ?? () #18 0x4808729b in ?? () #19 0x4807e11d in ?? () #20 0x480e7ebd in ?? () #21 0x8048e75 in ?? () #22 0x8048d61 in ?? () (kgdb) proc 2 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171ea5 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc023a52d in vm_pageout_scan () #9 0xc023af53 in vm_pageout () (kgdb) proc 288 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171cd4 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc023d038 in vnode_pager_lock () #9 0xc023060c in vm_fault () #10 0xc0284b9e in trap_pfault () #11 0xc0284663 in trap () #12 0x807e5e7 in ?? () #13 0x807dfb4 in ?? () #14 0x80595d1 in ?? () #15 0x805e6d8 in ?? () #16 0x805d5fa in ?? () #17 0x805e271 in ?? () #18 0x80589ab in ?? () #19 0x805bec5 in ?? () #20 0x804f1e1 in ?? () (kgdb) proc 13771 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171ea5 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc01a01b3 in vfs_cache_lookup () #9 0xc022e44d in ufs_vnoperate () #10 0xc01a3179 in lookup () #11 0xc01a2c74 in namei () #12 0xc01ab45f in vn_open () #13 0xc01a7568 in open () #14 0xc028520d in syscall2 () #15 0xc02767b5 in Xint0x80_syscall () #16 0x807a646 in ?? () #17 0x80755ca in ?? () #18 0x8056052 in ?? () #19 0x804ea19 in ?? () (kgdb) proc 13775 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171e88 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc02290d4 in ufs_ihashget () #9 0xc02265de in ffs_vget () #10 0xc022b964 in ufs_root () #11 0xc01a32b6 in lookup () #12 0xc01a2c74 in namei () #13 0xc01a86b5 in stat () #14 0xc028520d in syscall2 () #15 0xc02767b5 in Xint0x80_syscall () #16 0x806334f in ?? () #17 0x8063add in ?? () #18 0x805e9b6 in ?? () #19 0x8055ece in ?? () #20 0x8056825 in ?? () #21 0x804ea19 in ?? () (kgdb) proc 13779 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171e88 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc02290d4 in ufs_ihashget () #9 0xc02265de in ffs_vget () #10 0xc022b964 in ufs_root () #11 0xc01a32b6 in lookup () #12 0xc01a2c74 in namei () #13 0xc01ab45f in vn_open () #14 0xc01a7568 in open () #15 0xc028520d in syscall2 () #16 0xc02767b5 in Xint0x80_syscall () #17 0x807280e in ?? () #18 0x805e387 in ?? () #19 0x805e96c in ?? () #20 0x8055ece in ?? () #21 0x8056825 in ?? () #22 0x804ea19 in ?? () (kgdb) proc 13781 (kgdb) bt #0 0xc017ad88 in mi_switch () #1 0xc017a529 in tsleep () #2 0xc0171c24 in acquire () #3 0xc0171e88 in lockmgr () #4 0xc01a2008 in vop_stdlock () #5 0xc022e44d in ufs_vnoperate () #6 0xc01ac04b in vn_lock () #7 0xc01a4e18 in vget () #8 0xc01a01b3 in vfs_cache_lookup () #9 0xc022e44d in ufs_vnoperate () #10 0xc01a3179 in lookup () #11 0xc01a2c74 in namei () #12 0xc01ab45f in vn_open () #13 0xc01a7568 in open () #14 0xc028520d in syscall2 () #15 0xc02767b5 in Xint0x80_syscall () #16 0x804efd3 in ?? () #17 0x8055f10 in ?? () #18 0x8056825 in ?? () #19 0x804ea19 in ?? () To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: closeing files in detach()
> I wrote the driver against -CURRENT, but browsing through > on a 4.4-STABLE box reveals that specfs is in use there, too. I haven't > been trying my driver out against -STABLE yet, but -CURRENT works just fine. > > typedef struct specinfo *dev_t; > ^ this is what I have in 4.4-STABLE. Oops... It seems this is what you get with -D_KERNEL, but userland programs see an int. Ok. thanx! brad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com driver problems (fixed)
On Sun, 16 Dec 2001 [EMAIL PROTECTED] wrote: > ping is not a very good test...one of the reasons that most people cant find > problems generally. plus you want to use smaller packets to get the pps up. > The ave size packet is under 400 bytes on the net and it better simulates > real life. Once you saturate the wire the lockup occurs rather > quicklyyou have to get to the point where the overflows are happening > faster than the machine can process the interupts. Blah blah blah blah blah. I know ping isn't a great network diagnostic tool, but it allowed me to see the problem easily. You're welcome to run further tests with your flooder of choice to confirm my findings. The problem with stats interrupts causing slowdown was indeed due to a bug in our driver, and not some hardware bug. I have fixed the bug and committed the fix to -current; the fix will be MFC'd in a day or two, before the 4.5 codefreeze begins. In the meantime, you can grab the diff out of cvsweb if you're interested. And yes, it was pretty bad. The reason I didn't notice it too much is because stats interrupts were disabled under -current as a temporary fix; that change never got ported back to 4.x. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Instead of JFS, why not a whole new FS?
How about writing a new filesystem based on UFS? This would save all of the hassle that JFS would bring: licensing, porting time, etc. Of course, it would likely bust any compatibility desired. What I'm thinking is a filesystem that takes the current UFS and improves upon it. It could support larger partitions, more partitions in a slice, and perhaps a "Journal" partition (like the current "swap" partition) among other new features. What do others have to say about this? Are there any major flaws in my idea? It just seems to me that this would cut a lot of hassle. Those are just my $0.02. I know I've said it before, but I wasn't nearly as clear last time. -Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
It is possible that Kirk may be thinking about doing this. He mumbled something about a new FS a while ago but it wasn't clear whether he was thinking of doing it, or he was just saying "someone will eventually do it". On Mon, 17 Dec 2001, Dave Reyenga wrote: > How about writing a new filesystem based on UFS? This would save all of the > hassle that JFS would bring: licensing, porting time, etc. Of course, it > would likely bust any compatibility desired. > > What I'm thinking is a filesystem that takes the current UFS and improves > upon it. It could support larger partitions, more partitions in a slice, and > perhaps a "Journal" partition (like the current "swap" partition) among > other new features. > > What do others have to say about this? Are there any major flaws in my idea? > It just seems to me that this would cut a lot of hassle. > > Those are just my $0.02. I know I've said it before, but I wasn't nearly as > clear last time. > > -Craig > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
--- Dave Reyenga <[EMAIL PROTECTED]> wrote: > How about writing a new filesystem based on UFS? > This would save all of the > hassle that JFS would bring: licensing, porting > time, etc. Of course, it > would likely bust any compatibility desired. hi, first of all, a project called UFS2 has been started by Kirk McKusick on improving the existing UFS file system and improving 'softupdates' and other stuff in this file system. > What I'm thinking is a filesystem that takes the > current UFS and improves > upon it. It could support larger partitions, more > partitions in a slice, and > perhaps a "Journal" partition (like the current > "swap" partition) among > other new features. I dont know that this could be possible of having a 'Journal' partition, though I may be wrong. > What do others have to say about this? Are there any > major flaws in my idea? > It just seems to me that this would cut a lot of > hassle. One flaw in your idea is, that it would literally take longer to make this kind of file system on our current UFS source base. The reason is due to the code maturity level that UFS has reached of around 20 years. I think porting JFS will take less time than upgrading the current UFS, which as a matter of fact has already been started by Kirk McKusick himself. Regarding 'hassle', for me; nothing is a hassle as long as it can be acheived. If you are really interested in upgrading the current UFS, it would be good if you got in touch with Kirk McKusick himself. regards, =Hiten =<[EMAIL PROTECTED]> = =Hiten =<[EMAIL PROTECTED]> __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
JFS4BSD Project @ SourceForge.net
Hello, Greetings, Regarding the 'JFS for FreeBSD' discussion, I have started a project at SourceForge.net, which is for the porting of JFS. If you would like to join the JFS4BSD team in porting the JFS to the FreeBSD Operating System, please do not hesitate to either send a mail through SourceForge.net or send me an email at: [EMAIL PROTECTED], and write the following in the subject: "[subscribe] jfs4bsd", which will help me sort the mail out for the subscription. Everyone is welcome! Note: You will need an account at SourceForge in order to join any project including 'jfs4bsd'. The following are the details for the project: Project Full Name: JFS for FreeBSD (JFS4BSD) Project Unix Name: jfs4bsd CVS Server: cvs.jfs4bsd.sourceforge.net Web Site: jfs4bsd.sourceforge.net If you are not intending to join the project, please ignore this mail. Thank You for your co-operation, Regards, Hiten Pandya <[EMAIL PROTECTED]> __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
In article <001301c1874d$50ae0d20$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > How about writing a new filesystem based on UFS? This would save all of the > hassle that JFS would bring: licensing, porting time, etc. Of course, it > would likely bust any compatibility desired. > > What I'm thinking is a filesystem that takes the current UFS and improves > upon it. It could support larger partitions, more partitions in a slice, and > perhaps a "Journal" partition (like the current "swap" partition) among > other new features. > > What do others have to say about this? Are there any major flaws in my idea? > It just seems to me that this would cut a lot of hassle. If I might: "Why?". UFS/FFS is/are proven through time. Throw in the softupdates technology, and you have the upside of journalling, without the downside of journalling. No. I'm not going into details, first because I'm not qualified, and second, others already have. Was it Matt? I don't recall now, who made the observation, [sic] "Why does the Linux camp get so excited about the support for so many filesystems? Pick one, and make it the best you can.". In a recent thread about NFS performance, one post mentioned that ReiserFS died quite early in the test. If it's that much better, why didn't it survive that much better? The one thing that journalling FSes deliver that FFS with softupdates doesn't right now is a 'fsck'less boot after an uncontrolled shutdown. I have read that the Project has this on their TODO list. I know a post like this one can start a flameware for statements made without facts to back them up, but the facts exist, have been pointed out many times, and I don't want to mis-quote or mis-appropriate them. > Those are just my $0.02. I know I've said it before, but I wasn't nearly as > clear last time. > > -Craig And this is just my two-cents' worth, as well. Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
On Monday, 17 December 2001 at 22:50:45 -, Dave Reyenga wrote: > How about writing a new filesystem based on UFS? If it's based on UFS, it's not a new file system. > This would save all of the hassle that JFS would bring: licensing, > porting time, etc. There are no hassles with licensing. You'd be balancing porting time against writing time. Guess which would take longer. > What I'm thinking is a filesystem that takes the current UFS and > improves upon it. It could support larger partitions, That's relatively trivial. The big issue is compatibility. > more partitions in a slice, That's relatively trivial. The big issue is compatibility. > and perhaps a "Journal" partition (like the current "swap" > partition) Well, I don't think the journal would be like swap. > among other new features. That's pretty much what IBM did. They called the result JFS. 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
FREE CELLULAR PHONE OFFER-GUARANTEED APPROVAL
NOW YOU CAN RECEIVE A FREE CELLULAR PHONE FROM GMC AUTHORIZED DEALER FOR AT&T,WORLDCOM,SPRINT,VOICESTREAM,VERIZON AND CINGULAR. WE HAVE MANY MODELS& STYLES TO CHOOSE FROM LIKE THE NOKIA 3390,MOTOROLA STARTEC AND THE NOKIA 8260.WE GUARANTEE YOUR APPROVAL REGARDLESS OF YOUR PAST CREDIT HISTORY. ALL PHONES COMES WITH CALLER ID, VOICEMAIL,CALL WAITING AND EMAIL TEXT MESSAGING. SOME PHONES EVEN HAVE A WEB BROWSER TO SURF THE INTERNET.THE PHONES ARE 100% FREE WITH ACTIVATION. THE RATE PLANS START AT $19.99 PER MONTH,SOME PLANS HAVE UNLIMITED NIGHTS AND WEEKENDS WITH FREE LONG DISTANCE. THIS IS A LIMITED OFFER! YOU CAN HAVE YOUR PHONE DELIVERED IN 48 HOURS. FOR MORE INFORMATION OR TO ORDER YOUR PHONE CALL 1-866-206-0820 THATS 1-866-206-0820. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
On Mon, Dec 17, 2001 at 05:25:07PM -0600, D J Hawkey Jr wrote: > The one thing that journalling FSes deliver that FFS with softupdates doesn't > right now is a 'fsck'less boot after an uncontrolled shutdown. I have read > that the Project has this on their TODO list. This has been the default in -current for a few months now. It requires snapshots, which hasn't been MFC'd yet. Joe msg30236/pgp0.pgp Description: PGP signature
Re: Instead of JFS, why not a whole new FS?
Dave Reyenga wrote: > > How about writing a new filesystem based on UFS? This would save all of the > hassle that JFS would bring: licensing, porting time, etc. Of course, it > would likely bust any compatibility desired. > > What I'm thinking is a filesystem that takes the current UFS and improves > upon it. It could support larger partitions, more partitions in a slice, and > perhaps a "Journal" partition (like the current "swap" partition) among > other new features. > > What do others have to say about this? Are there any major flaws in my idea? > It just seems to me that this would cut a lot of hassle. Any FS that shares code with an existing FS will not flush out the full list of problems associated with writing a new FS in the context of a FreeBSD system. For that reason, any UFS based system, including but not limited to FFS, LFS, EXT2FS, etc., is probably not a good example to use for an educational project. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
:... :>with out-of-order operations from nfsiod's that apparently may come :>up after a week or so of testing. I asked Jordan to try to track down :>the NeXT guy who fixed that one in the old NFS stack. : :This bug showed up recently here with fsx testing. I seem to have fixed it :last week in MacOS X. The diffs were widespread but the idea was simple :enough so a few code snippets should suffice: : :nfs_request gets a new argument (u_int64_t *xidp) and fills it in here: : :... Ok, I understand. That will probably be a little too complex to make the 4.5 release, but I'll do it post-4.5. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What a FBSD FS needs to do?
On Mon, 17 Dec 2001, Terry Lambert wrote: [...snippage all over...] wow! thanks! that was much more than i'd hoped for! unfortunately i'm very much a beginner to kernel hacking, so don't expect any ported filesystems out of me in the near future... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
