interface flags
Hi, i have freebsd 4.2 stable. what is difference between interface flags IFF_UP and IFF_RUNNING? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctl to disable reboot
On Tue, May 22, 2001 at 09:43:01AM +0800, David Xu wrote: Hello Jon, Tuesday, May 22, 2001, 12:30:44 AM, you wrote: JP I thought it would be useful to have a sysctl for disabling the JP keyboard reboot sequence. This functionality is currently JP available through the SC_DISABLE_REBOOT config option, but it's JP convenient to have this capability available at runtime, too. [snip] I have already failed many times to persuade them to add a sysctl about keyboard reboot, they prefer to change a keymap file and allow everyone to load it into kernel. You can always compile a keymap into the kernel, and disable loading any other keymaps. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Perfmon device
Hi, I sent this question to freebsd-questions but haven't got any answer, yet. That is why I'm now trying here. Here is my question. I have noticed that every time the perfmon device is closed it shuts down the PMECs. While I can see this is appropriate for some applications, it is not for mine. I'm using the PMECs for measuring the performance of some in-kernel networking routines. It would be very useful for me to be able to use the perfmon device just for configuring the PMECs. But as it is distributed this is not possible. I see two solutions to this. One is to extend the device's implementation for supporting a close without stopping ioctl command. Because this implies knowing the details of the device's driver, and because right now I need a fast solution, I cannot do this. The other is a brute force (and naive, if you will) solution; that is, eliminate the code in perfmon_close() that shuts down the PMECs. This code seams to be at perfmon_fini(), where perfmon_stop() is called and perfmon_inuse is updated. However, I do not want to do this until I'm sure such a change is safe. So my question is, can I do such a change an still get a working device? If no, is there some other way to accomplish this? Other derived questions. Is there some other way for on-line configuring the PMECs? Any comment on the proposed extension for the device? TIA, -- 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: [EMAIL PROTECTED]| Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187| Jordi Girona, 1-3 U P C fax:+34 93 401 7055| 08034 Barcelona - SPAIN WWW:http://people.ac.upc.es/homes/oscar/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctl to disable reboot
Mon, May 21, 2001 at 18:46:57, imp (Warner Losh) wrote about Re: sysctl to disable reboot: : In addition, I prefer my approach here because it's a single, : known toggle that doesn't involve messing with other parts of the : system. I might just want to disable keyboard rebooting : temporarily. This seems like the most intuitive way to do so. Bah. I'm trying to fight feaping creaturism. I'm not worried about the most intuitive way :-). Seriously, this is unix. You need to use the right tools for the right jobs. Reboot, and a host of other things, are controlled via the keymap. This is current situation and is more ugly and hackly than logic. Keymap is choice of user on consoles. Disabling reboot is choice of root. If you allow only root to use virtual consoles you're right. Instead, you use guillotine against headache. Creating a keymap w/o the reboot (or other objectionable options) in it is the easiest way to deal with the problem. This will be ugly hack, not right way. And if you prefer this way you should remove SC_DISABLE_REBOOT option to make things complete. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
No Subject
Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
mylex raid card problem on 4.2-stable
Hi all, We have a quite disapointing problem with a mylex 170 card, which causes a system crash every 6 hours. This card is installed in a VA Linux 2240 with 4 18GB drives, configured in a single RAID 5 pack, running a FreeBSD 4.2-stable system. We have to notice that this system ran during 4 months without any problem, and that we have many other servers running this configuration without any kind of problem. The kernel output says : mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok This message is repeated every 30 seconds and, after arround 3 hours, the server hangs. Sometimes, we've got this one : mly0 : Got AM completion for nonbusy Slot 0 Generally, the server runs during 3 hours without messages, then 3 hours with the message mly0: enclosure 1 temperature sensor 0 failed (...) For a test purpose, we tried to hot extract one of the drives, and we plugged it in again. Then, the card rebuilt the pack, and the system ran without problems during 15 days. Finaly, the problem comes back again with the same messages. Any kind of help would be very appreciated. Thanx -- --- -- [EMAIL PROTECTED] --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -R for make update ?
Wilko Bulte wrote: Hi Is there any specific reason why one needs to be able to write a lock to the CVS repo when running 'make update' to get a freshly checked out source? Yeah: you aren't running your CVS server in pserver mode, and so are trying to do a lock, either in your local copy, or over NFS. If you run your repository in pserver mode, the CVS server will be connected to over the network, instead of attacking your CVS repo directly, and you won't have the problem you are seeing, since the cvs server will be able to get the lock, no problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RE: vmspace leak (+ tentative fix)
On 22-May-01 Matt Dillon wrote: :Ok, then why not let the current shmexit() stay in exit1() as a hack to help :free memory, but add in a check in vmspace_free() as well to catch any race :conditions that may fall through the cracks? As long as we clear the shm :pointer in struct vmspace when we free it then we won't be double free'ing, :and :will always free it eventually. That is also a much simpler change. :) :Additionally, adding to the comment in exit1() clarifying that this is an :attempt to free resources as soon as possible and that the race condition is :known and that vmspace_free() is a catch-all might be nice as well. : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ :PGP Key: http://www.baldwin.cx/~john/pgpkey.asc It's not really good programming practice. Someone might trip over it later on. Then the vmspace free()ing is also bad programming practice? It's the same exact algorithm used for the vmspace. -Matt -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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
what is a good toolkit for multitarget documentation?
hey folks, i am currently evaluating different styles of implementing documentation for some multiplatform software stuff. first i though about html only docs, but this is not sufficient. then i thought about tex docs but this wont work out either. the idea is to have a single 'master repo' style document tree that can be used to dump out - html all-in-one-file and chapters - tex for pretty printing and pdf output - man pages - README, CHANGES and auxiliary documentation text files is sgml/docbook the way to go? i've seen that the freebsd handbook and other documents obviously are written using the docbook dtd, but i cannot find any pointers what software are involved in creating readable documents. i actually found a short editor/opensp/jadetex/tex howto but this would just replace the main functionality of latex, and that's not what i want. i guess my tex speaking skills are better than sgml ;-) as this seems to be arbitrary complicated, depending on the parsers and filters used, is there a) a simpler way of doing this? b) a recommended, standard, way? another question is, if it is possible to 'fold' certain paragraphs or whole chapters based on the assumption that we generate one handbook for beginners and a slightly different one for advanced users and one with source code snippets -- or even whole source files with annotations -- for developers. thx in advance! cheers, /k -- Worry is interest paid before a debt is due. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Albert D. Cahalan wrote: It should be immediately obvious that ext2 is NOT the filesystem being proposed, async or not. For large directories, ext2 sucks as bad as UFS does. This is because ext2 is a UFS clone. The proposed filesystem is most likely Reiserfs. This is a true journalling filesystem with a radically non-traditional layout. It is no problem to put millions of files in a single directory. (actually, the all-in-one approach performs better than a tree) XFS and JFS are similarly capable, but Reiserfs is well tested and part of the official Linux kernel. You can get the Reiserfs team to support you too, in case you want to bypass the normal filesystem interface for even better performance. Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. I think Linus has some reservations about the stability of the filesystem since it is fairly new. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). Heck, the system didn't even try to boot when it came back, I had to pull out the rescue disk and run fsck from there. Good thing the rescue disk was the same as the install disk, it saved me a disk swap. :( If only FreeBSD could boot from those funky M-Systems flash disks. So, no async here, and UFS + soft updates can't touch the performance on huge directories. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: interface flags
As it says in sys/net/if.h, IFF_RUNNING means resources allocated and IFF_UP means interface is up. As I interpret this, the difference is that IFF_RUNNING is set when the interface is initialised and indicates that it is ready to be used. IFF_UP on the other hand is set by the user to indicate whether this interface is enabled or not. I.e. IFF_RUNNING set by system, IFF_UP set by user. This however, doesn't seem to be the case in all drivers though. I would be very pleased if someone could clarify the issue further. Please correct me if I'm totally wrong! regards Mårten Wikström -Original Message- From: vishwanath pargaonkar To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 5/22/01 8:52 AM Subject: interface flags Hi, i have freebsd 4.2 stable. what is difference between interface flags IFF_UP and IFF_RUNNING? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD/powerpc work to date
On Mon, 21 May 2001, Benno Rice wrote: Please feel free to review, comment, etc. The snapshot is in the form of a diff against -CURRENT and a tar.gz file containing new files that would need to be committed. Both of these files are rooted in src/sys. Nice! Reading through the changes, I have a couple of comments. In mp_machdep.c, you should remove the 'include machine/rpb.h' - that is only ever likely to exist on alpha. You can alsp delete ipl.h since that has been removed for the other arches. In swtch.s, you are correct in thinking that Idle is unneeded. A generic assembler question - why the use of _C_LABEL(xx)? Surely since we are only ever going to be using ELF here, we can assume the format of C names? Its difficult to see what is happening since I'm not familiar with powerpc assembler but it appears that you are saving the process state on the stack (using a 'struct switchframe'). The other architectures save this information in the PCB - I'm not sure which is the best place. I notice that pmap.c contains a mix of programming styles with some of the code using ANSI and some KR. The trend seems to be to move to ANSI for all new code so its probably worth converting the rest of the file. How far does the beast get when booting? -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
[trimming CCs] On Tue, May 22, 2001 at 09:31:34AM -0400, Jason Andresen wrote: Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. I think Linus has some reservations about the stability of the filesystem since it is fairly new. It is in now AFAIK. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). Heck, the system didn't even try to boot when it came back, I had to pull FWIW, I lost two filesystems last week. One ext2 and the second reiser and no crashes/power failures were involved. The ext2 failure meant a complete reinstall (only 4-5 files where left in / after fsck). A reiser filesystem started giving input/output errors and could not be repaired with reiserfsck. Trying to back up the file system before a repair only resulted in kernel panics. -- Hroi Sigurdsson [EMAIL PROTECTED] Netgroup A/S http://www.netgroup.dk To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Albert D. Cahalan wrote: Gordon Tetlow writes: On Mon, 21 May 2001, Jordan Hubbard wrote: [Charles C. Figueire] c) A filesystem that will be fast in light of tens of thousands of files in a single directory (maybe even hundreds of thousands) I think we can more than hold our own with UFS + soft updates. This is another area where you need to get hard numbers from the Linux folks. I think your assumption that Linux handles this effectively is flawed and I'd like to see hard numbers which prove otherwise; you should demand no less. Also point out the reliability factor here which is a bit harder to point to a magic number and See, we *are* better! ext2 runs async by default which can lead to nasty filesystem corruption in the event of a power loss. With softupdates, the filesystem metadata will always be in sync and uncorrupted (barring media failure of course). It should be immediately obvious that ext2 is NOT the filesystem being proposed, async or not. For large directories, ext2 sucks as bad as UFS does. This is because ext2 is a UFS clone. The proposed filesystem is most likely Reiserfs. This is a true journalling filesystem with a radically non-traditional layout. It is no problem to put millions of files in a single directory. (actually, the all-in-one approach performs better than a tree) XFS and JFS are similarly capable, but Reiserfs is well tested and part of the official Linux kernel. You can get the Reiserfs team to support you too, in case you want to bypass the normal filesystem interface for even better performance. So, no async here, and UFS + soft updates can't touch the performance on huge directories. Unfortunatly I don't have a ReiserFS partition available to test with, but I do have UFS and ext2fs partitions. Here's the results I got from postmark, which seems to be the closest match to the original problem in the entire ports tree. Test setup: Two machines with the same make and model hardware, one running FreeBSD 4.0, the other running RedHat Linux 7.0. The data: Hardware: Both machines have the same hardware on paper (although it is TWO machines, YMMV). PII-300 Intel PIIX4 ATA33 controller IBM-DHEA-38451 8063MB ata0-master using UDMA33 HD Note: all variables are left at default unless mentioned. 1 transactions, 500 files. FreeBSD 4.0 +Softupdates, write cache disabled: Time: 35 seconds total 34 seconds of transactions (294 per second) Files: 5513 created (157 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 5013 files (147 per second) 4917 read (144 per second) 5016 appended (147 per second) 5513 deleted (157 per second) Deletion alone: 526 files (526 per second) Mixed with transactions: 4987 files (146 per second) Data: 31.27 megabytes read (893.48 kilobytes per second) 34.71 megabytes written (991.70 kilobytes per second) Linux 2.2.16 ext2fs and write caching enabled Time: 28 seconds total 28 seconds of transactions (357 per second) Files: 5513 created (196 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 5013 files (179 per second) 4917 read (175 per second) 5016 appended (179 per second) 5513 deleted (196 per second) Deletion alone: 526 files (526 per second) Mixed with transactions: 4987 files (178 per second) Data: 31.27 megabytes read (1.12 megabytes per second) 34.71 megabytes written (1.24 megabytes per second) 1 transactions, 3 files: FreeBSD 4.0 +softupdates, write cache disabled: Time: 640 seconds total 410 seconds of transactions (24 per second) Files: 34993 created (54 per second) Creation alone: 3 files (146 per second) Mixed with transactions: 4993 files (12 per second) 5055 read (12 per second) 4944 appended (12 per second) 34993 deleted (54 per second) Deletion alone: 29986 files (1199 per second) Mixed with transactions: 5007 files (12 per second) Data: 25.62 megabytes read (40.03 kilobytes per second) 179.79 megabytes written (280.92 kilobytes per second) Linux 2.2.16 ext2fs with write caching enabled Time: 1009 seconds total 612 seconds of transactions (16 per second) Files: 34993 created (34 per second) Creation alone: 3 files (83 per second) Mixed with transactions: 4993 files (8 per second) 5055 read (8 per second) 4944 appended (8 per second) 34993 deleted (34 per second) Deletion alone: 29986 files (768 per second) Mixed with transactions: 5007 files (8 per second) Data: 25.62 megabytes read
Re: technical comparison
Jason Andresen wrote: Oops, I fubbed up the linux at 6 files test, I'm rerunning it now, but it will take a while to finish. Results: ufs+softupdates is a little slower than ext2fs+wc for low numbers of files, but scales better. I wish I had a Reiserfs partition to test with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: what is a good toolkit for multitarget documentation?
If memory serves me right, Karsten W. Rohrbach wrote: i am currently evaluating different styles of implementing documentation for some multiplatform software stuff. first i though about html only docs, but this is not sufficient. then i thought about tex docs but this wont work out either. the idea is to have a single 'master repo' style document tree that can be used to dump out - html all-in-one-file and chapters - tex for pretty printing and pdf output - man pages - README, CHANGES and auxiliary documentation text files is sgml/docbook the way to go? i've seen that the freebsd handbook and other documents obviously are written using the docbook dtd, but i cannot find any pointers what software are involved in creating readable documents. SGML and DocBook are *one* way to go to do this. It's pretty easy to do HTML, by-chapters HTML, PDF, PS, text, and a few other formats. You can build multiple renderings of a document (such as the Handbook) like this: % cd /usr/doc/en_US.ISO_8859-1/books/handbook % make 'FORMATS=html pdf txt' Yes, it's kind of complicated. Fortunately the FreeBSD Documentation Project infrastructure makes a lot of the pain go away. I'd browse around through the FreeBSD Documentation Project Primer for New Contributors, which is available at, among other places: http://www.freebsd.org/tutorials/docproj-primer/index.html Also look through the doc/ tree a little bit, in particular the Makefiles (look through some of the articles; they tend to be less complicated than the books). Note that if you have the doc/ tree and the textproc/ docproj meta-port installed, you can use a lot of the common Makefile stuff and you don't need to worry about the exact mechanics of how SGML gets turned into, for example, PDF. I'm working on a paper right now which has nothing to do with FreeBSD, but it uses a lot of the Makefile infrastructure from the FDP. Obviously this means I'd have some problems building on non-FreeBSD machines, but I don't consider that to be a huge problem at the moment. another question is, if it is possible to 'fold' certain paragraphs or whole chapters based on the assumption that we generate one handbook for beginners and a slightly different one for advanced users and one with source code snippets -- or even whole source files with annotations -- for developers. Yes, you can do this in a couple of ways. One way is to do some conditional inclusion of text using SGML entities (see the section on using INCLUDE and IGNORE in marked sections in the FDP Primer...the copy I have shows it in section 3.8.1.2). Another way (which requires some stylesheet hacking) is to add some attribute support. RELNOTESng for -CURRENT does this for release note items that pertain only to specific architectures. I started this with marked sections as above, but decided to use attributes because we'll need its greater flexibility later. Hope this helps, Bruce. PGP signature
Re: technical comparison
Jason Andresen wrote: Jason Andresen wrote: Oops, I fubbed up the linux at 6 files test, I'm rerunning it now, but it will take a while to finish. Results: ufs+softupdates is a little slower than ext2fs+wc for low numbers of files, but scales better. I wish I had a Reiserfs partition to test with. The test is done: Linux 2.2.16 with ext2fs and write caching 1 transactions, 6 simultanious files: Time: 2084 seconds total 702 seconds of transactions (14 per second) Files: 65065 created (31 per second) Creation alone: 6 files (48 per second) Mixed with transactions: 5065 files (7 per second) 5078 read (7 per second) 4921 appended (7 per second) 65065 deleted (31 per second) Deletion alone: 60130 files (395 per second) Mixed with transactions: 4935 files (7 per second) Data: 26.01 megabytes read (12.48 kilobytes per second) 325.12 megabytes written (156.01 kilobytes per second) I don't suppose anybody has a FreeBSD and Linux box dual booting (or identically speced) with ReiserFS anywhere? I'm quite curious how much faster ReiserFS is in these tests. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mylex raid card problem on 4.2-stable
At 12:34 PM 5/22/2001 +0200, julien wrote: Hi all, We have a quite disapointing problem with a mylex 170 card, which causes a system crash every 6 hours. This card is installed in a VA Linux 2240 with 4 18GB drives, configured in a single RAID 5 pack, running a FreeBSD 4.2-stable system. We have to notice that this system ran during 4 months without any problem, and that we have many other servers running this configuration without any kind of problem. The kernel output says : mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok I don't know much about the mylex cards but have you checked the temp sensor in the enclosure it mentions? Have you checked to see if maybe it's faulty or something? --Larry Lawrence Sica - Systems Administrator - Interactivate, Inc. [EMAIL PROTECTED] http://www.interactivate.com -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
According to Brian Somers: If pppctl is still working (ppp will talk to it), then it may be worth seeing what ``show physical'' and ``show timer'' say (is the link open, or is ppp waiting for something to happen via a timeout?). Locked again with a pppctl attached. show timer -=-=- IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.00s, state = running physical throughput timer[0x80af068]: freq = 1.00s, next = 0.90s, state = running hdlc timer[0x80b1d84]: freq = 60.00s, next = 22.90s, state = running -=-=- show physical -=-=- Name: deflink State: open (established) Device: PPPoE:ed0: Link Type: background Connect Count: 1 Queued Packets: 0 Phone Number:N/A Defaults: Device List: PPPoE:ed0: Characteristics: sync, cs8, no parity, CTS/RTS on CD check delay: device specific Connect time: 24:08:11 14864337 octets in, 8655370 octets out 56740 packets in, 56238 packets out overall 270 bytes/sec currently 0 bytes/sec in, 0 bytes/sec out (over the last 5 secs) peak 70148 bytes/sec on Mon May 21 20:02:16 2001 -=-=- show lcp -=-=- PPP ON keltia show lcp deflink: LCP [Opened] his side: MRU 1492, ACCMAP , PROTOCOMP off, ACFCOMP off, MAGIC 6317ffaa, MRRU 0, SHORTSEQ off, REJECT my side: MRU 1500, ACCMAP , PROTOCOMP off, ACFCOMP off, MAGIC 0c7a6a1f, MRRU 0, SHORTSEQ on, REJECT Defaults: MRU = 1492, ACCMAP = LQR period = 30s, Open Mode = active (delay 1s) FSM retry = 3s, max 5 Config REQs, 5 Term REQs Ident: Negotiation: ACFCOMP = disabled denied CHAP = disabled accepted CHAP80 =disabled accepted LANMan =disabled accepted CHAP81 =disabled accepted LQR = disabled denied PAP = disabled accepted PROTOCOMP = disabled accepted -=-=- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mylex raid card problem on 4.2-stable
Hi, In fact, I don't really believe in a hardware problem like a false contact on a temp sensor. I also noticed that a boot time, itstays blocked at "waiting 15s for scsi device to settle" during arround 10 min what would indicate that it's more an OS / driver problem. In my previous mail, I indicated that it runs under 4.2-stable, in fact itwas 4.2-release. I updated the system to 4.3-rc2, which has a mly driver code 5 month older (2001-03) than on 4.2-release (2000-10). I'm waiting to see what will happen. thanx for your help --- [EMAIL PROTECTED]--- - Original Message - From: "Lawrence Sica`" [EMAIL PROTECTED] To: "julien" [EMAIL PROTECTED]; [EMAIL PROTECTED]; "cristophe baillon" [EMAIL PROTECTED] Sent: Tuesday, May 22, 2001 6:52 PM Subject: Re: mylex raid card problem on 4.2-stable At 12:34 PM 5/22/2001 +0200, julien wrote: Hi all, We have a quite disapointing problem with a mylex 170 card, which causes a system crash every 6 hours. This card is installed in a VA Linux 2240 with 4 18GB drives, configured in a single RAID 5 pack, running a FreeBSD 4.2-stable system. We have to notice that this system ran during 4 months without any problem, and that we have many other servers running this configuration without any kind of problem. The kernel output says : mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok mly0: enclosure 1 temperature sensor 0 failed mly0: enclosure 1 temperature sensor 0 ok I don't know much about the mylex cards but have you checked the temp sensor in the enclosure it mentions? Have you checked to see if maybe it's faulty or something? --Larry Lawrence Sica - Systems Administrator - Interactivate, Inc. [EMAIL PROTECTED] http://www.interactivate.com -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical comparison
] I work in an environment consisting of 300+ systems, all FreeBSD ] and Solaris, along with lots of EMC and F5 stuff. Our engineering division ] has been working on a dynamic content server and search engine for the ] past 2.5 years. They have consistently not met up to performance and ] throughput requirements and have always blamed our use of FreeBSD for it. You may wish to point out to them that their F5 boxes are running FreeBSD. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Jason Andresen writes: Albert D. Cahalan wrote: It should be immediately obvious that ext2 is NOT the filesystem being proposed, async or not. For large directories, ext2 sucks as bad as UFS does. This is because ext2 is a UFS clone. The proposed filesystem is most likely Reiserfs. This is a true journalling filesystem with a radically non-traditional layout. It is no problem to put millions of files in a single directory. (actually, the all-in-one approach performs better than a tree) XFS and JFS are similarly capable, but Reiserfs is well tested and part of the official Linux kernel. You can get the Reiserfs team to support you too, in case you want to bypass the normal filesystem interface for even better performance. Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. I think Linus has some reservations about the stability of the filesystem since it is It is in the kernel: http://lxr.linux.no/source/fs/reiserfs/?v=2.4.4 Bugs died left and right when it went in. fairly new. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). If you don't like ext2, why should it like you? :-) I power cycle a Linux box nearly every day to reset a board. If only FreeBSD could boot from those funky M-Systems flash disks. If you want flash, use a filesystem designed for flash. (not UFS, ext2, Reiserfs, XFS, JFS, or FAT... try JFFS2) So, no async here, and UFS + soft updates can't touch the performance on huge directories. From another email you mention benchmarking with: Linux 2.2.16 with ext2fs and write caching 1 transactions, 6 simultanious files: 1. The 2.2.16 kernel is obsolete. 2. 6 files is not a lot. Try a few million files. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: technical comparison
-Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 10:59 AM To: [EMAIL PROTECTED] Subject: Re: technical comparison ] I work in an environment consisting of 300+ systems, all FreeBSD ] and Solaris, along with lots of EMC and F5 stuff. Our engineering division ] has been working on a dynamic content server and search engine for the ] past 2.5 years. They have consistently not met up to performance and ] throughput requirements and have always blamed our use of FreeBSD for it. You may wish to point out to them that their F5 boxes are running FreeBSD. Terry Lambert [EMAIL PROTECTED] When did that change? As of March which was the last time I had my grubby little hands all over a F5 BigIP box in our lab, it was NOT running FreeBSD. It runs a tweaked version of BSDI's kernel. Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Albert D. Cahalan wrote: Jason Andresen writes: Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. I think Linus has some reservations about the stability of the filesystem since it is It is in the kernel: http://lxr.linux.no/source/fs/reiserfs/?v=2.4.4 Bugs died left and right when it went in. Looks like my news was out of date. Thanks for the update. fairly new. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). If you don't like ext2, why should it like you? :-) I power cycle a Linux box nearly every day to reset a board. If only FreeBSD could boot from those funky M-Systems flash disks. If you want flash, use a filesystem designed for flash. (not UFS, ext2, Reiserfs, XFS, JFS, or FAT... try JFFS2) So, no async here, and UFS + soft updates can't touch the performance on huge directories. From another email you mention benchmarking with: Linux 2.2.16 with ext2fs and write caching 1 transactions, 6 simultanious files: 1. The 2.2.16 kernel is obsolete. 2. 6 files is not a lot. Try a few million files. 6 files took ~15 minutes to create as is. I'm going to have to wait until tonight to run larger sets. 2.2.16 is what we have here. I'm still waiting to see how much faster ReiserFS is. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. Linux (2.2.14-5 + ReiserFS): Time: 164 seconds total 97 seconds of transactions (103 per second) Files: 65052 created (396 per second) Creation alone: 6 files (1090 per second) Mixed with transactions: 5052 files (52 per second) 4936 read (50 per second) 5063 appended (52 per second) 65052 deleted (396 per second) Deletion alone: 60104 files (5008 per second) Mixed with transactions: 4948 files (51 per second) Data: 24.83 megabytes read (155.01 kilobytes per second) 336.87 megabytes written (2.05 megabytes per second) FreeBSD 4.3-RELEASE (ufs/softupdates): Time: 537 seconds total 155 seconds of transactions (64 per second) Files: 65052 created (121 per second) Creation alone: 6 files (172 per second) Mixed with transactions: 5052 files (32 per second) 4936 read (31 per second) 5063 appended (32 per second) 65052 deleted (121 per second) Deletion alone: 60104 files (1717 per second) Mixed with transactions: 4948 files (31 per second) Data: 24.83 megabytes read (47.34 kilobytes per second) 336.87 megabytes written (642.38 kilobytes per second) Both tests were done with postmark-1.5, 6 files in 1 transactions. The machines are IBM Netfinity 4000R, the disk is an IBM DPSS-336950N, connected to an Adaptec 2940UW. Nadav To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 12:40:11PM -0600, Matt Simerson wrote: When did that change? As of March which was the last time I had my grubby little hands all over a F5 BigIP box in our lab, it was NOT running FreeBSD. It runs a tweaked version of BSDI's kernel. I believe it is Terry's information that's out of date, not yours. -- 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: technical comparison
ReiserFS entered Linux kernels in the pre 2.4.1 series, and was 'official' with 2.4.1. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -R for make update ?
On Tue, May 22, 2001 at 04:00:31AM -0700, Terry Lambert wrote: Is there any specific reason why one needs to be able to write a lock to the CVS repo when running 'make update' to get a freshly checked out source? Yeah: you aren't running your CVS server in pserver mode, and so are trying to do a lock, either in your local copy, or over NFS. If you run your repository in pserver mode, the CVS server will be connected to over the network, instead of attacking your CVS repo directly, and you won't have the problem you are seeing, since the cvs server will be able to get the lock, no problem. It will also be freakishly slow, and use massive amounts of temp space. Kris PGP signature
Re: -R for make update ?
Is there any specific reason why one needs to be able to write a lock to the CVS repo when running 'make update' to get a freshly checked out source? Yeah: you aren't running your CVS server in pserver mode, and so are trying to do a lock, either in your local copy, or over NFS. If you run your repository in pserver mode, the CVS server will be connected to over the network, instead of attacking your CVS repo directly, and you won't have the problem you are seeing, since the cvs server will be able to get the lock, no problem. It will also be freakishly slow, and use massive amounts of temp space. No slower than cvs using rsh/ssh, although it does tend to create alot of inodes in /tmp. (It doesn't create alot of temp space, other than what is used to create the directories...) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RE: vmspace leak (+ tentative fix)
: : :On 22-May-01 Matt Dillon wrote: ::Ok, then why not let the current shmexit() stay in exit1() as a hack to help ::free memory, but add in a check in vmspace_free() as well to catch any race ::conditions that may fall through the cracks? As long as we clear the shm ::pointer in struct vmspace when we free it then we won't be double free'ing, ::and ::will always free it eventually. That is also a much simpler change. :) ::Additionally, adding to the comment in exit1() clarifying that this is an ::attempt to free resources as soon as possible and that the race condition is ::known and that vmspace_free() is a catch-all might be nice as well. :: ::-- :: ::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ ::PGP Key: http://www.baldwin.cx/~john/pgpkey.asc : :It's not really good programming practice. Someone might trip over :it later on. : :Then the vmspace free()ing is also bad programming practice? It's the same :exact algorithm used for the vmspace. : : -Matt : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ Huh? It doesn't look like the same algorithm to me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RE: vmspace leak (+ tentative fix)
On 22-May-01 Matt Dillon wrote: : : :On 22-May-01 Matt Dillon wrote: ::Ok, then why not let the current shmexit() stay in exit1() as a hack to ::help ::free memory, but add in a check in vmspace_free() as well to catch any race ::conditions that may fall through the cracks? As long as we clear the shm ::pointer in struct vmspace when we free it then we won't be double free'ing, ::and ::will always free it eventually. That is also a much simpler change. :) ::Additionally, adding to the comment in exit1() clarifying that this is an ::attempt to free resources as soon as possible and that the race condition ::is ::known and that vmspace_free() is a catch-all might be nice as well. :: ::-- :: ::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ ::PGP Key: http://www.baldwin.cx/~john/pgpkey.asc : :It's not really good programming practice. Someone might trip over :it later on. : :Then the vmspace free()ing is also bad programming practice? It's the same :exact algorithm used for the vmspace. : : -Matt : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ Huh? It doesn't look like the same algorithm to me. In exit1() we attempt to free resources early if we can. If we lose the race, we still clean it up in vmspace_free() called from cpu_wait(). If you check the shm pointer and do shmexit() in vmspace_free() just as is done in vmspace_free(), then you will catch any cases that fall through with the shm not being free'd using the same technique currently employed in releasing the vmspace and with a minimal amount of change to the code. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc 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: RE: vmspace leak (+ tentative fix)
:: ::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ : : Huh? It doesn't look like the same algorithm to me. : :In exit1() we attempt to free resources early if we can. If we lose the race, :we still clean it up in vmspace_free() called from cpu_wait(). If you check :the shm pointer and do shmexit() in vmspace_free() just as is done in :vmspace_free(), then you will catch any cases that fall through with the shm :not being free'd using the same technique currently employed in releasing the :vmspace and with a minimal amount of change to the code. : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ The whole point is to release resources as early as possible. Why would you ever want to intentionally introduce a race that will 'sometimes' be lost and thus cause a late resource release when you can just as easily completely guarentee that the resource will be released early, and thus never have to worry about it. That makes no sense at all. From the point of view of algorithm design, it's much better to know what *will* happen rather then what *might* happen. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -R for make update ?
On Tue, May 22, 2001 at 02:15:18PM -0600, Nate Williams wrote: Is there any specific reason why one needs to be able to write a lock to the CVS repo when running 'make update' to get a freshly checked out source? Yeah: you aren't running your CVS server in pserver mode, and so are trying to do a lock, either in your local copy, or over NFS. If you run your repository in pserver mode, the CVS server will be connected to over the network, instead of attacking your CVS repo directly, and you won't have the problem you are seeing, since the cvs server will be able to get the lock, no problem. It will also be freakishly slow, and use massive amounts of temp space. No slower than cvs using rsh/ssh, although it does tend to create alot of inodes in /tmp. (It doesn't create alot of temp space, other than what is used to create the directories...) Yes, using rsh/ssh is also slow, but we were talking about *local* access, which has none of those drawbacks. -R makes cvs operations go quite a bit faster, and AFAIK is perfectly safe if you're using a private repo for which you know there will be no contention. Kris PGP signature
Re: RE: vmspace leak (+ tentative fix)
On 22-May-01 Matt Dillon wrote: :: ::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ : : Huh? It doesn't look like the same algorithm to me. : :In exit1() we attempt to free resources early if we can. If we lose the :race, :we still clean it up in vmspace_free() called from cpu_wait(). If you check :the shm pointer and do shmexit() in vmspace_free() just as is done in :vmspace_free(), then you will catch any cases that fall through with the shm :not being free'd using the same technique currently employed in releasing the :vmspace and with a minimal amount of change to the code. : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ The whole point is to release resources as early as possible. Why would you ever want to intentionally introduce a race that will 'sometimes' be lost and thus cause a late resource release when you can just as easily completely guarentee that the resource will be released early, and thus never have to worry about it. That makes no sense at all. From the point of view of algorithm design, it's much better to know what *will* happen rather then what *might* happen. Then do you want to fix the race for the vmspace release as well? If so, that makes sense. Only doing one and not the other makes no sense though. It seemed you only wanted to close the shmexit() race but not the one for releasing the user pages. *shrug* -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc 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: technical comparison
On Tue, May 22, 2001 at 10:27:27PM +0300, Nadav Eiron wrote: I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. Linux (2.2.14-5 + ReiserFS): Time: 164 seconds total 97 seconds of transactions (103 per second) Files: 65052 created (396 per second) Creation alone: 6 files (1090 per second) Mixed with transactions: 5052 files (52 per second) 4936 read (50 per second) 5063 appended (52 per second) 65052 deleted (396 per second) Deletion alone: 60104 files (5008 per second) Mixed with transactions: 4948 files (51 per second) Data: 24.83 megabytes read (155.01 kilobytes per second) 336.87 megabytes written (2.05 megabytes per second) FreeBSD 4.3-RELEASE (ufs/softupdates): Did you enable write caching? You didn't mention, and it's off by default in 4.3, but I think enabled by default on Linux. Kris PGP signature
Re: RE: vmspace leak (+ tentative fix)
: : The whole point is to release resources as early as possible. Why would : you ever want to intentionally introduce a race that will 'sometimes' be : lost and thus cause a late resource release when you can just as easily : completely guarentee that the resource will be released early, and thus : never have to worry about it. That makes no sense at all. From the : point of view of algorithm design, it's much better to know what *will* : happen rather then what *might* happen. : :Then do you want to fix the race for the vmspace release as well? If so, that :makes sense. Only doing one and not the other makes no sense though. It :seemed you only wanted to close the shmexit() race but not the one for :releasing the user pages. *shrug* : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ The patch I suggested removes the race, period. So all the code in the initial conditional gets run... the shmexit as well as releasing the user pages. Since the two are side by side it would be kinda difficult to run one but not the other so I'm not sure where the confusion could have been introduced. We might also want to add the shmexit to the vmspace_free() code for completeness, but that would require more research to determine whether it's safe to do there or not. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
I didn't, but I believe Jason's numbers (for ext2 and ufs) also had write caching only enabled on Linux. On Tue, 22 May 2001, Kris Kennaway wrote: On Tue, May 22, 2001 at 10:27:27PM +0300, Nadav Eiron wrote: I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. Linux (2.2.14-5 + ReiserFS): Time: 164 seconds total 97 seconds of transactions (103 per second) Files: 65052 created (396 per second) Creation alone: 6 files (1090 per second) Mixed with transactions: 5052 files (52 per second) 4936 read (50 per second) 5063 appended (52 per second) 65052 deleted (396 per second) Deletion alone: 60104 files (5008 per second) Mixed with transactions: 4948 files (51 per second) Data: 24.83 megabytes read (155.01 kilobytes per second) 336.87 megabytes written (2.05 megabytes per second) FreeBSD 4.3-RELEASE (ufs/softupdates): Did you enable write caching? You didn't mention, and it's off by default in 4.3, but I think enabled by default on Linux. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Jason Andresen wrote: If only FreeBSD could boot from those funky M-Systems flash disks. It can. -- 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: technical comparison
Jason Andresen wrote: Results: ufs+softupdates is a little slower than ext2fs+wc for low numbers of files, but scales better. I wish I had a Reiserfs partition to test with. Ext2fs is a non-contender. Note, though, that there is some very recent perfomance improvement on very large directories known as dirpref (what changed, actually, was dirpref's algorithm). This is NOT present on 4.3-RELEASE, though it _might_ have since been committed to stable. -- 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: technical comparison
Nadav Eiron wrote: I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. For that matter, did you have vfs.vmiodirenable enabled? -- 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: technical comparison
On Tue, May 22, 2001 at 02:49:21PM -0400, Jason Andresen wrote: 6 files took ~15 minutes to create as is. I'm going to have to wait until tonight to run larger sets. 2.2.16 is what we have here. I'm still waiting to see how much faster ReiserFS is. I'm willing to overnight your test if you want. Do you have it packaged up to send? It would be interesting just to get numbers from a Linux system with a modern kernel. 2.4.1 gave me enough of a speed boost to put off another FreeBSD install until I fix some problems there. I cannot test FreeBSD with SCSI right now so my system will be an inequal set of results. I would offer to test NetBSD as well, but I suppose no one would be interested in that. -- [EMAIL PROTECTED] _ __/ armchairrocketscientistgraffitiexistentialist There is no such thing as security. Life is either bold adventure, or it is nothing -- Helen Keller To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 09:31:34AM -0400, Jason Andresen wrote: Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. ReiserFS, on my system anyway, started just losing files. I'd log in and would notice some mp3 files or source code was just gone. No heavy load, and no crashes. Nope, not for me. I think they'll get it in time if the basic design isn't flawed, but things like an fs just take a lot of time to debug and come to trust. There are already some very good journaling systems, and it would seem better to get them ported, and leave things like ReiserFS a research project until it proves itself. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. Point taken, but the yank power, see who survives test is illogical and dangerous thinking. Besides, my drives have megabytes of write-cache that I cannot disable. Most are large enough to cause problems for most any fs if they crash at just the right moment. From what I have read, a lot of drives really ignore commands to turn it off or do synchronous writes. Both ext2 and ufs both handle my chores with little or no trouble. On some systems, I've actually preferred ufs to the journaled file systems. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). This is not typical. Also, I have heard the same thing from other people about flash disks. fs crash, fsck, and a mess afterwards. It would be nice if you could use ufs and see if the same problem exists. -- There's music along the river For Love wanders there, Pale | | | flowers on his mantle, Dark leaves on his hair. -- James Joyce | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Shannon Hendrix wrote: On Tue, May 22, 2001 at 02:49:21PM -0400, Jason Andresen wrote: 6 files took ~15 minutes to create as is. I'm going to have to wait until tonight to run larger sets. 2.2.16 is what we have here. I'm still waiting to see how much faster ReiserFS is. I'm willing to overnight your test if you want. Do you have it packaged up to send? It would be interesting just to get numbers from a Linux system with a modern kernel. 2.4.1 gave me enough of a speed boost to put off another FreeBSD install until I fix some problems there. I cannot test FreeBSD with SCSI right now so my system will be an inequal set of results. I would offer to test NetBSD as well, but I suppose no one would be interested in that. And just to get things worse... :-) the test must be made on the *same* slice. If you configure two different slices, the one on the outer tracks will be faster. -- 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: technical comparison
On Tue, May 22, 2001 at 12:03:33PM -0400, Jason Andresen wrote: Here's the results I got from postmark, which seems to be the closest match to the original problem in the entire ports tree. Test setup: Two machines with the same make and model hardware, one running FreeBSD 4.0, the other running RedHat Linux 7.0. The data: Hardware: Both machines have the same hardware on paper (although it is TWO machines, YMMV). PII-300 Intel PIIX4 ATA33 controller IBM-DHEA-38451 8063MB ata0-master using UDMA33 HD Note: all variables are left at default unless mentioned. 1 transactions, 500 files. What did you set size to? How much memory on the machine? I tested on a 700MHz Athlon system with 256MB RAM, Adaptec 2940UW controller, 18GB IBM Ultrastar SCSI drive. You must have really low memory or something because I know that 1 transactions and 500 files can't be enough for anything faster than my old Sun SS5. I hit over 16MB/sec and 5000 transactions per second on my Linux machine. On the larger tests, it was disappointing. I can't test FreeBSD on SCSI right now, but my NetBSD machine (the old Sun SS5 wasn't terrible at least: Time: 220 seconds total 204 seconds of transactions (49 per second) Files: 5564 created (25 per second) Creation alone: 500 files (62 per second) Mixed with transactions: 5064 files (24 per second) 4999 read (24 per second) 4967 appended (24 per second) 5564 deleted (25 per second) Deletion alone: 628 files (78 per second) Mixed with transactions: 4936 files (24 per second) Data: 32.12 megabytes read (149.52 kilobytes per second) 35.61 megabytes written (165.73 kilobytes per second) 1 transactions, 6 files FreeBSD 4.0 with Softupdates, write cache disabled Time: 1259 seconds total 495 seconds of transactions (20 per second) I got about 60 per second right here. I was actually expecting better results from Linux and NetBSD than I got, and would expect more from FreeBSD than you got. I'm going to test FreeBSD tomorrow and Linux again with much larger numbers of files and transactions. -- Star Wars Moral Number 17: Teddy bears are dangerous in| | | herds. | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 10:55:09PM -0300, Daniel C. Sobral wrote: And just to get things worse... :-) the test must be made on the *same* slice. If you configure two different slices, the one on the outer tracks will be faster. I cannot verify that with my drive, but my largest is 18GB so maybe the difference is not as pronounced as on some newer drives like those (currently) monster 70GB drives. A 70GB IBM Ultrastar supposedly can physically outrun the internal electronics on the faster tracks. One review I read mentioned it as a problem, though I'm not sure why. In any case, I'm not quite that picky, and I would not think that postmark would benefit as much from being on the faster tracks. It's doing a lot more complicated things than just streaming data. -- And in billows of might swell the Saxons before her,-- Unite, oh unite! Or the billows burst o'er her! -- Downfall of the Gael __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Nadav Eiron wrote: I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. [ ... ] Both tests were done with postmark-1.5, 6 files in 1 transactions. The machines are IBM Netfinity 4000R, the disk is an IBM DPSS-336950N, connected to an Adaptec 2940UW. I don't understand the inability to perform the trivial design engineering necessary to keep from needing to put 60,000 files in one directory. However, we can take it as a given that people who need to do this are incapable of doing computer science. I would suggest two things: 1) If write caching is off on the Linux disks, turn it off on the FreeBSD disks. 2) -- and then turn it on on both. 3) Modify the test to delete the files based on a directory traversal, instead of promiscuous knowledge of the file names, which is cheating to make the lookups appear faster. (the rationale behind this last is that people who can't design around needing 60,000 files in a single directory are probably going to to be unable to correctly remember the names of the files they created, since if they could, then they could remember things like ./a/a/aardvark or ./a/b/abominable). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, 22 May 2001, Shannon Hendrix wrote: : :Point taken, but the yank power, see who survives test is illogical :and dangerous thinking. Depends on the enviornment. I've had lots of machines just lose power. People will pull power cords out, the back-up generators won't start before the battery back-up runs out, someone will push the Big Red Switch. Even the best back-up power isn't going to help if it catches fire. I sort of like machines to work when the power comes back. -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
void wrote: On Tue, May 22, 2001 at 12:40:11PM -0600, Matt Simerson wrote: When did that change? As of March which was the last time I had my grubby little hands all over a F5 BigIP box in our lab, it was NOT running FreeBSD. It runs a tweaked version of BSDI's kernel. I believe it is Terry's information that's out of date, not yours. Yep; mea culpa. I guess they will just have to install BSDI systems in place of your FreeBSD and Linux systems. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Shannon Hendrix writes: On Tue, May 22, 2001 at 12:03:33PM -0400, Jason Andresen wrote: Here's the results I got from postmark, which seems to be the closest match to the original problem in the entire ports tree. Test setup: Two machines with the same make and model hardware, one running FreeBSD 4.0, the other running RedHat Linux 7.0. That should be FreeBSD 4.3 and Red Hat 7.1 at least, or -current and 2.4.5-pre5. Considering that this is about a new system, the latest software and hardware ought to be used. Reiserfs only became stable just recently; the 2.4.1 kernel would be a dumb choice. 1 transactions, 500 files. ... 1 transactions, 6 files Even 6 files is insignificant by Reiserfs standards. The test gets interesting with several million files. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
Terry Lambert writes: I don't understand the inability to perform the trivial design engineering necessary to keep from needing to put 60,000 files in one directory. However, we can take it as a given that people who need to do this are incapable of doing computer science. One could say the same about the design engineering necessary to handle 60,000 files in one directory. You're making excuses. People _want_ to do this, and it often performs better on a modern filesystem. This is not about need; it's about keeping ugly hacks out of the app code. http://www.namesys.com/5_1.html (the rationale behind this last is that people who can't design around needing 60,000 files in a single directory are probably going to to be unable to correctly remember the names of the files they created, since if they could, then they could remember things like ./a/a/aardvark or ./a/b/abominable). Eeew. ./a/b/abominable is a disgusting old hack used to work around traditional filesystem deficiencies. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
