: with your rather large diff set. For better or for worse, people
: already know about the daylight savings shift problem. Thousands
: of people depend on cron to work, which means that when you
: make a major change like this it must be tested by a wider audience
: for a
I think it is worth doing. A quick google search shows that
the linux folks discussed the AIX thingy in March 1999, but
I don't think they actually implemented. From the discussion,
it appears that the fcntl would be useful and (not having seen
your patches), almost
:
:At 10:33 26/01/01 -0800, Matt Dillon wrote:
: I think it is worth doing. A quick google search shows that
: the linux folks discussed the AIX thingy in March 1999, but
: I don't think they actually implemented. From the discussion,
: it appears that the fcntl would be useful
:
: I agree that breaking coherence is bad, though I find fcntl is the kind of
: functions to use when you don't have a more specific one:)
:
:do we have (or could we design) a generic mechanism for machine-specific
:syscalls which are not available on all OS ?
:
:basically i am thinking of
: As for the "generic" syscall mechanism, I'd love it. I think that
: there are many places where "names" would be good, instead of
: hardcoded numbers. The only problem is to find a way to do that
: without reducing performance. names are good. just try to see what it
: would be if filenames
:true, but if the same idea gets adopted by those many OSes, then it's a benefit
:for them all. just how PAM came: it was non-portabble before adoption!
:
It doesn't solve anything. Besides, there is no such thing as a
perfect hash ... at least not one that has a small enough index
:
:They say so in their book:
:
:http://www.amazon.com/exec/obidos/ASIN/0805316701/qid=980806275/sr=1-28/ref=sc_b_28/104-5366240-4220700
:
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
:FreeBSD committer | BSD since 4.3-tahoe
I like it, with some minor tweaks. I recommend:
* name the new function vm_map_findspace2() (or something similarly
short.
* change all callers of vm_map_findspace() to instead call
vm_map_findspace2() directly.
* depreciate the original
:vm.swapdev1.total (this is the one that is currently hard to get)
You can't move swapinfo into the kernel as a sysctl unless you
solve this problem. Traversing the radix tree is expensive enough
that the entire system will stall for a short period of time if you run
the loop
: VOP_SWAPACCOUNT(nbp-b_vp, nbp);
: BUF_KERNPROC(nbp);
: BUF_STRATEGY(nbp);
:
:Now, I have to define the vop in vm_swap.c, where I can get the area
:index from the block number in a clean way and frob my counters.
:The same method could be used in
:Yep. I only thought I should keep the layering by using VOPs. But you
:are right, swap_pager and vm_swap are dependent anyway, so this can
:be justified, and things are not duplicated over the whole file.
:So, is it OK with you if I do it the way you described?
:
: - thomas
Yes, I
It doesn't make sense to pollute 'mdconfig' with functions that we already
have an API available to perform. An API called 'mount'.
Why not write a 'mount_md' program to do all the magic based on fstab
options, similar to what mount_mfs used to do for MFS? A 'mount_md'
would
:Some thoughts:
:
: - If you want softupdates, you need to specify the -S flag. Should
:softupdates be the default?
That's a hard one. Considering that people who have mfs in their fstab
probably expect as little disk I/O as possible, softupdate sshould
probably be enabled by
:I'm playing with an application that uses dlopen() to load some libraries. I
:use the _init function to set the libraries up. I've also set up the _fini
:functions to shut things down.
:
:I see, in the man page, that dlclose() will unload the libraries and call
:_fini.
:
:My question is whether
:| The files are accessed approximately 3 or 4 times a day on average.
:| Older files are archived for reference purpose and may never
:| be accessed after a week.
:|
:| Ok, this is a start. Now is the 70 TB the size of the active files?
:| Or does that also include the older archived files
:2^31 x 512 bytes = 1 TB on Intel boxes. Our NFS implementation has the
:same per-filesystem limitation. Theoretically UFS/FFS are limited
Oops. I meant, per-file limitation for NFS clients, not per-filesystem.
1TB per file.
I think before you guys go off wandering you need some definitive
information on the rate of incomming and outgoing mail, number of
simultanious connections being handled, and so forth.
On the face of it, high disk transaction rates, low transfer rates,
and idle cpu implies
Also:
* ps axlww
* dmesg
* pstat -s
* 'vmstat 1' output for a good 20 seconds.
(during the period of heavy disk I/O).
In re: to softupdates. It should make a huge difference for mail
applications. If it doesn't, then perhaps it isn't compiled into
your
(also: do not use async mounts with softupdates. Just enable softupdates
with tunefs, then mount the filesystem normally).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the
:ok of those commands some interesting info was from dmesg...
:on one machine i had
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:file: table is full
:
:In message [EMAIL PROTECTED],
:Charles Randall writes:
:The qmail FAQ specifically recommends against soft updates for the mail
:queue.
:
:http://cr.yp.to/qmail/faq/reliability.html#filesystems
:
:Is this incorrect?
:
:
:It seems to indicate that qmail doesn't use fsync(2) as much as it
:
:On Mon, 5 Feb 2001, Matt Dillon wrote:
:
: :file: table is full
:
: :looutput: mbuf allocation failed
: :nfs server 172.16.0.101:/bravenet1/home: is alive again
:
: This sheds a considerable amount of light on the problems...
: methinks you may have a low 'maxusers' setting
:softupdates disk may wind up unwinding 'more' of the last few moments
:worth of operations then a normal filesystem would. And, I might add,
:Reiser is the same way.
:
:The only way to guarentee that file data is written to disk, with any
:filesystem no matter how it is
:Well, the various qmail programs do seem to fsync (though I'm not sure if
:it's in the right places.) In any case, this link seems to throw some
:light on the situation:
:
:ftp://elektroni.ee.tut.fi/pub/qmail_linux_metadata_message
:
:Now, I have no clue if this is correct or not, but the core
:with fsync(), so softupdates is not going to be too much worse then
:other FS's.
:
:Actually, if you don't use fsync you do loose more work with
:softupdates than if you use plain UFS.
:
:Softupdates can delay directory updates which plain UFS will runs
:synchronously, and consequently
:kirk said (but I have not completely checked it) that if you fsync a file,
:it will effectively fsync all the way back to the root of the filesystem.
:
:I don't know how true this is, but cerainly the inode is updated before
:fsync returns. I cannot tell if any directory entries pointing at
: consistent state. Softupdates is considerably better at guarenteeing
: this consistency (as is something like Reiser), but if you crash a
: softupdates disk may wind up unwinding 'more' of the last few moments
: worth of operations then a normal filesystem would. And, I might
:Poul-Henning Kamp wrote:
:
: In message [EMAIL PROTECTED],
:Charles Randall writes:
: The qmail FAQ specifically recommends against soft updates for the mail
: queue.
:
: http://cr.yp.to/qmail/faq/reliability.html#filesystems
:
: Is this incorrect?
:
:
: It seems to indicate that qmail
:PW
:PWI have a 15K rpm drive if you want to do a recalculation. I think that
:PWis 1.05Mach, depending on whether you rounded or not. ;-)
:
:Well, 7cm gives 21cm per rotation or 2.1km for 1 rotations. 1
:Rotations Per Minute give around 130km per hour which is somewhere around
:On Tue, 6 Feb 2001, Matt Dillon wrote:
:
: I did a quick search of the qmail site but couldn't find an email
: address to report the FAQ issue to. If QMail calls fsync() in a
: reasonable manner, then softupdates is perfectly safe and the QMail
: FAQ needs to be updated
: Pre-softupdate BSD semantics, apparently. Doesn't sound like
: the smartest thing to do when you want a reliable MTA...
:
:This description is not entirely right.
:
:Qmail depends on ordered-metadata updates (Terry! :-). That means
:if you issue a link() to the new place and a unlink() in the
:
:This information is in fact correct. Have a look at the FreeBSD link(2)
:man page:
:
:LINK(2) FreeBSD System Calls Manual
:LINK(2)
Andre, I think there *might* be a dozen people in the world that
understand UFS/FFS better then I do, but none of them
: banging on unrelated areas of the filesystem in parallel, and an
: fsync() of one descriptor would have to wait for the entire filesystem
: to reach a synchronization point to guarentee metadata update ordering.
: This creates a serious scaleability issue within a filesystem!
:
up the load and looking into vinum.
:
:Regards,
:
:Dan
:
:
:On Wed, 7 Feb 2001, Andrew Reilly wrote:
:
: Date: Wed, 7 Feb 2001 14:12:25 +1100
: From: Andrew Reilly [EMAIL PROTECTED]
: To: Alfred Perlstein [EMAIL PROTECTED]
: Cc: Andre Oppermann [EMAIL PROTECTED],
: Matt Dillon [EMAIL PROTECTED
:Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
:like to much about postfix is that it only tries one MX record and then
:does not try any others"default"yes there is still backlog with
:#'s I gave you. Right now 8 min to get an email from sending...I have
:
:Don't forget to put logging and other such things on a separate drive..
:even a small 1G drive as a secondary will be ok, as long as it has soft
:updates and doesn't share heads with the work area..
:
:vmstat 1 and iostat 1 output would be intersting.
:
:--
: __--_|\ Julian Elischer
: already existing?
:
:Why not just read the man page for rename(2) before making
:suggestions?
:
:I did. I'm glad I was right that it's deleting the destination that is
:the problem. I would have thought it would be easy to be sure that
:spool filenames are unique, but OTOH I guess that's not
:Here's an idea for a new /etc/malloc.conf option to help with
:debugging... I'm interested in what other people think.
:
:The option would have the effect of setting a "failure probability"
:P between 0.0 and 1.0 such that any malloc()/realloc() operation would
:fail with probability P.
:...
:
Well, after a long conversation with Mr Bernstein and Kirk it turns out
that all my blathering about a normal FFS mount being easily corruptable
due to a crash occuring during heavy disk I/O (e.g. from qmail) is so
much smoke.
The fsync()/rename() combination that QMail does
:I do. Is it safe there as well (from your point of view)?
:
:--
:Andre
Yes. In general softupdates will make the entire filesystem safer.
The commit sequencing doesn't match what qmail expects, but there
are so many fsyncs going on that the absolute worse that can happen
in a
:
:Matt Dillon wrote:
:
: Yes. In general softupdates will make the entire filesystem safer.
:
:Does it make sense to use softupdates on file systems like / and
:/usr which have little file creation/removal?
:
:Greg
I have had softupdates turned on for all of my mount points for over
: mmap - allocate memory, or map files or devices into memory
:
: would be better?
:
:You have my vote. That information would have saved me quite a few
:hours of angst a few years ago when I was looking for a way to share
:memory between processes. In fact, it will probably be an
:Maybe I'm suffering a temporary lapse of clue, but is there some
:place where supplemental info (like code snippets) is kept? This
:kind of info might be handy to someone seeing the man page for the
:first time, but it doesn't seem quite right to put code samples
:in the man pages themselves.
: My recommendation is to turn softupdates on for everything you have,
: and for us to make it a newfs default as well. At least in -stable.
:You use softupdates turned on for all of your ufs.
:Understand.
:What is the reason to use softupdates for file system
:with only atime updates on
:OK, I'm sold on the general idea of using soft updates; but what
:sort of performance improvements should I expect to see?
:
:I do a kernel compile on a freshly-rebooted box with an without
:softupdates; without, it took 20m45s and with soft updates it
:still took 20m10s --- this is less than 3%
: In fact, it's exactly the opposite. 'make world' is CPU-bound, so the
: speed of the I/O system is irrelevant. If it were I/O bound, soft
: updates *would* make a difference, because a number of unnecessary
: writes would be eliminated.
:
:Read what he writes. Soft updates *did* make a
:Thunderbird 900, with 256 MB of PC-133 memory, and using 3 - ATA-66
:HD's on different controllers. The elapsed time dropped from 58:16 to
:45:54 by using softupdates.
:
:Kent
That sounds about right for -pipe. The original email was
1 hour vs 40 minutes, a 20 minute difference which
:...
:da2: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device
:da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing
:Enabled
:da2: 8715MB (1785 512 byte sectors: 255H 63S/T C)
:
:3 drives in there as of 3 min ago.
:just want to take these 3 and raid0 then
:
:So, if I send problem report with my patches, I should inherit usage of
:staticaly allocated buffers.
:Am I right?
:
:milunovic [EMAIL PROTECTED] wrote in message
:[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
: -BEGIN PGP SIGNED MESSAGE-
:
: On Fri, 16 Feb 2001, Andrey Simonenko
:: hold one line from parsed file. Usually it is enough for one line, but
::...
:
:Yes. System libraries traditionally use statically allocated buffers
:because, even now, there is no dynamic equivalent for fgets(). The
:closest you can get is to mmap() the file and extract the
: fgets() with the proper length limitation, using a statically allocated
: buffer is not a big deal. Most configuration files couldn't have long
: lines and still be legal anyway.
:
:Note that the classical loop
:while (fgets(buf, n, fp) != NULL) {
: tokenize(buf,
:Is the following portable and safe?
:
:Given n different structure declarations, where each structure begins
:with the same member type, can any instance of any of the structures
:be cast to the (pointer) type of the first member?
:
:e.g.
:
: struct foo {
: const char *s;
: ...
:
:On Sat, Feb 24, 2001 at 04:08:04PM -0500, David Gilbert wrote:
: We have an application which is precompiled, for linux, and stupid.
: It uses (at times large) scratch files. We want to run this on our
: diskless machines (CPU farm) to cut the per-cpu cost of the
: computation ($200/drive
:Hmmm... I was just having a little fun, and I think that someone's
:using the wrong type of integer somewhere:
:
:[1:23:323]root@news:~ vnconfig -e -s labels -S 1t vn0
:[1:24:324]root@news:~ disklabel -r -w vn0 auto
:[1:25:325]root@news:~ newfs /dev/vn0c
:preposterous size -2147483648
:
:Dave.
:Making the run for larger block sizes puts us in the same league as
:DOS. While it will stave off the wolves, it will only work for so
:long give Moore's law.
:
:Dave.
:
:--
:
:|David Gilbert, Velocet Communications.
:With 512 Byte blocksizes you are limited to 1T because the physical
:block number is a signed 32bit.
:FFS uses 32bit (I wouldn't count on the high bit) frag numbers.
:A fragment defaults to 1k so even with 1k fragments the limit is
:at least 2T.
Yes, the FFS limit is essentially the frag
:...
: : merging such a feature?
:
: Assuming that it doesn't break anything, that it doesn't introduce a
: severe performance penalty and works, there would be interest. There
: are times that this is a desirable feature.
:
:This thread reminds me of what happened when I brought up the same
:In message [EMAIL PROTECTED], "Daniel C. Sobral" writes:
:OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
:*wants* that feature to sit down and code it. It won't happen otherwise.
:
:So, out of idle curiousity: If, somewhere down the road, I know the kernel
:well
:Matt Dillon wrote:
:
:..
: the system runs out of memory, even *with* overcommit protection.
: In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just see how
much goes flying
: :...
: :
: :That's an assumption.
:
: Ha. Right. Go through any piece of significant code and just see how
: much goes flying out the window because the code wants to simply assume
: things work. Then try coding conditionals all the way through to fix
: it... and don't
(owner-freebsd-hackers removed from list)
:You're implying that you are making two calls to create the same
:directory. Am I correct?
:
:The answer is 'maybe'? Depends on the remote NFS server. Matt or one
:of the other NFS gurus may know more, but I wouldn't count on *anything*
:over
:
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive
: things work. Then try coding conditionals all the way through to fix
: it... and don't forget you need to propogate the error condition back
: up the procedure chain too so the original caller knows why it failed.
:
:So, it all comes down to reimplementing the UNIX kernel in a
Daniel, you don't have to believe me, I really don't care. I hear this
argument once or twice a year and those of who actually have experience
(except for Terry, who always likes to argue theory) already know what
the reality is. Come back in a year or two after you've wasted a
This is an extremely dangerous patch. A number of terminal protocols
have a 'talkback' escape sequence that allow you to write data
that the terminal then copies back as if someone typed it. I remember
using this feature quite a lot while at Berkeley to, ah, break into
people's
: is it possible to actually find out whether data hit the disk or not for
: a particular run of 1-7?
:
:Answer to your question:
:
:Do an msync with MS_SYNC someplace. Also, use MAP_NOSYNC in
:mmap until 4.3 when Matt Dillon plans to make that the default behavior.
I plan on making
Hmm. Well, mlock() is one of those system calls that virtually
nobody has worked on since inception. The most I've done with it
has been to fix bugs. The resource issues for mlock() aren't
really good enough to prevent misuse in a general multiuser system.
The resource is
::Along the same lines (matt probably knows the answer) is it
::easy to force paging in and locking down of any memory associated
::with a process so that mlockall(MCL_FUTURE) together with
::an appropriate memorylocked limit gives the requested
::memory semantics? I'd have to check through the
I was browsing CompUSA today and noticed they were selling Sony
VAIO 1.3 and 1.5 GHz desktops, amoung other things. It's amazing
how fast processors have gotten just in the last two years! I just
had to pick up one of these babies and give it a run through to see
how fast
:You should see what speed RamBus they were using, 600 or 800 Mhz. It is
:pretty fast for large memory writes and reads. It'd be cool to see how
:the different speeds stack up against one another. DDR comparisons would
:be cool too. Yeah, for the frequency, you have to take into account that
:On Mon, 5 Mar 2001, E.B. Dreger wrote:
:
:I've got a ServerWorks III HE-SL system with 512MB of two-way
:interleaved PC133 SDRAM and dual PIII-800's. Is that close enough?
::-)
:
:Here is my "memory bandwidth test", much much simpler and less
:scientific than Matt's:
:
:dd if=/dev/zero
:throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its
:overclocked) here on my desk with 256KB L2 cache:
:
:dd if=/dev/zero of=/dev/null bs=512k count=4000
:4000+0 records in
:4000+0 records out
:2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec)
:
:dd
:IIRC, Intel is using a very different caching method on the P4 from
:what we are used to on just about every other x86 processor we've
:seen. Well, I can't remember if the data cache has changed much, but
:the instruction cache has. I doubt the difference in instruction
:cache behaviour would
:systat -vmstat
:
:Disks ad0 acd0 fd0 md0 89 ofodintrn
:KB/t 4.35 0.00 0.00 0.00 85 %slo-z61952 buf
:tps 13 0 0 0 104 tfree42 dirtybuf
:MB/s 0.05 0.00 0.00 0.00 36095 desiredvnodes
:% busy
:
:
:
:this is a webserver ..i am trying to figure out if cpu increase or
:scsi drives is better in this situation. Right now...that is a big
:decision because there are approx 30 fbsd webservers not all showing
:high IO from vmstat...just the ones with the highest uptime.
:...
:Well we use php mostly. I noticed from moving from php3 to php4
:memory consumption on webservers was just incredible and had to
:increase ram from 256 megs to 500megs on each of webservers.
:Memory is fine now.
:
:[root@lotho dphoenix]# ps aux|grep httpd|wc -l
: 65
:[root@lotho dphoenix]#
:I am trying to figure out corelation between Inactive and Free then.
:Inact would be unused ram right?
:Free would be what how much of Active is being used? So what you are
:saying is if there is to much free then alot of active pages are being
:killed for some reason...as seen in error logs
:How's your P4 for floating point? Is real-life perf as good as the
:specbench numbers would indicate, or do you need a better compiler
:than GCC to get any benefit from it? My wife is a statistician, and
:she runs some really fp intensive workloads. This Athlon is faster
:than the Serverworks
:Which begs the question I've tried to ask a number of times in different
:forums. Who's working on P4 optimizations and code generation for the P4?
I'd be happy if GCC -O2 just worked without introducing bugs. I want to
be able to compile the kernel with it again.
:
:This explained in great detail exactly why people are seeing the performance
:they are from the P4 etc. The author knows his stuff.
:
:http://www.emulators.com/pentium4.htm
:
:Brandon
Heh heh. You can practically see the sweat popping off his face while
reading his article.
:
:The people involved know.
:
Harrruummm. (Gong!)
Harrruummm. (Gong!)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:On Mon, Mar 05, 2001 at 06:08:25PM -0800, Matt Dillon wrote:
:
: :I am trying to figure out corelation between Inactive and Free then.
: :Inact would be unused ram right?
: :Free would be what how much of Active is being used? So what you are
: :saying is if there is to much free then alot
:I am running a system with a 50GB /home drive. One user is experiencing
:inconsistencies, for him the system reports being over disk quota.
:du -sk reports 1.7GB utilization, quota reports 5.2GB. I've been checking
:the entire drive for files that belong to this user, same result. I have
:About a year ago, I was looking through the VM code, and saw that the
:'re' field in vmstat is just Cache reactivations, and not both
:Inactive Cache. I just figured it was how it was supposed to be.
:Could it be that 're' should include *all* reactivations?
:
:If so, would I be correct in
:What production volumes are required before ASICs are feasible? What
:about having a FreeBSD CDROM + NIC bundle featuring whatever card gets
:designed?
:
:If ya can't join 'em, beat 'em.
:
:Okay. Back to work and reality. :-)
:
:Eddy
Designing an ASIC will have an NRE of probably around
You can't safely do FP instructions in the kernel. I do not
believe the FP context is saved/restored between processes in kernel
mode, only from user mode. The kernel saves and restores the fp state
in the few places it uses FP instructions (for memory copying).
In anycase,
:
:Noted.
:
:Is there a gcc PR associated with this?
:
:http://gcc.gnu.org/cgi-bin/gnatsweb.pl
:
:A GNATS searc for "freebsd kernel" didn't return anything.
:
:-Charles
No idea. Somewhere around 4.1 my -O2 and -Os kernel compiles just
stopped working. There was a bunch of stuff on
:It will use all available memory for disk caching if possible, but it
:only caches things you've accessed at least once so I would say you
:simply haven't accessed more then 650MB or so worth of file data.
:
:Is it correct to say that cached file data (file content)
:is taken into
:I don't really think that portalfs is the right thing to use to build
:an httpfs with, but I would like to see how you managed to get your example
:to work. Are you using stdout to create an anonymous file handle? What happens
:if two processes concurrently read from /p/http/*?
:
:Duncan
:
:--
One thing that comes to mind is that you can smarthost your outgoing
email to another host so the queues don't build up. This should
greatly reduce mail load. In fact, I would recommend offloading email
entirely if possible... email always hits disks hard.
Definitely get
:md0/MFS is used for caching the articles that BBS users read.
:They often read the same articles over and over again,
:and we find that a 128MB MFS/md0 will have 70% hitrate
:
:When our MFS/md0 fills up after long usage, the box easily
:dies. (We crontab clean the mfs, but sometimes the load
:
:How much SHM? Like, what's the combined size of all segments in
:the system? You can make SHM non-pageable which results in a lot
:of saved memory for attached processes.
:
:You want to be after this date and have this file:
:
:
:Revision 1.3.2.3 / (download) - annotate - [select for diffs],
:| How big is 'lots'? If the shared memory segment is smallish, e.g.
:| less then 64MB, you should be ok. If it is larger then you will
:| have to do some kernel tuning to avoid running out of pmap entries.
:
:This is exactly what happens to us sometimes. We run out of pmap
:Another problem is that we have around 4000+ processes accessing
:lots of SHM at the same time..
How big is 'lots'? If the shared memory segment is smallish, e.g.
less then 64MB, you should be ok. If it is larger then you will
have to do some kernel tuning to avoid running out of
:If this is a result of the shared memory, then my sysctl should fix it.
:
:Be aware, that it doesn't fix it on the fly! You must drop and recreate
:the shared memory segments.
:
:better to reboot actually and set the variable before any shm is
:allocated.
:
:--
:-Alfred Perlstein - [[EMAIL
:Hey, talking about large amounts of swap, did you know that:
: 4.2-STABLE FreeBSD 4.2-STABLE #1: Sat Feb 10 01:26:41 PST 2001
:has a max swap limit that's possibly 'low':
:
: b: 159124120 swap# (Cyl.0 - 990*)
: c: 179124120unused0
:B) Added 3gb of swap on one drive, 1gb of swap on a raid volume
: another 1gb swap on another raid volume
:C) enabled vfs.vmiodirenable and kern.ipc.shm_use_phys
:
:--
:+---+
:| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
:* Rik van Riel [EMAIL PROTECTED] [010321 09:51] wrote:
: On Wed, 21 Mar 2001, Peter Wemm wrote:
:
: Also, 4MB = 1024 pages, at 28 bytes per mapping == 28k per process.
:
: 28 bytes/mapping is a LOT. I've implemented an (admittedly
: not completely architecture-independent) reverse mapping
:
:(Why is vfs.vmiodirenable=1 not enabled by default?)
:
The only reason it isn't enabled by default is some unresolved
filesystem corruption that occurs very rarely (with or without
it) that Kirk and I are still trying to nail down. I want to get
that figured out first.
It
:Matt Dillon [EMAIL PROTECTED] writes:
: So you would be able to create approximately four 17GB swap partitions.
: If you reduce NSWAP to 2 you would be able to create approximately
: two 34GB swap partitions. If you reduce NSWAP to 1 you would be able
: to create approximately
1 - 100 of 412 matches
Mail list logo
