In message [EMAIL PROTECTED], A G F Keahan writes:
What parameters should I choose for a large (say, 60 or 80Gb)
filesystem? I remember a while ago someone (phk?) conducted a survey,
but nothing seems to have come of it. In the meantime, the capacity of
an average hard drive has increased
* Poul-Henning Kamp [EMAIL PROTECTED] [001207 00:12] wrote:
In message [EMAIL PROTECTED], A G F Keahan writes:
What parameters should I choose for a large (say, 60 or 80Gb)
filesystem? I remember a while ago someone (phk?) conducted a survey,
but nothing seems to have come of it. In the
:
: Right now I tend to use:
:
: -b 16384 -f 4096 -c 159
:
:I know you're pretty busy, but any chance of getting this into
:sysinstall? Maybe hindged on the size of the partition?
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
:"I have the heart of a child; I keep it
:In message [EMAIL PROTECTED], A G F Keahan writes:
:What parameters should I choose for a large (say, 60 or 80Gb)
:filesystem? I remember a while ago someone (phk?) conducted a survey,
:but nothing seems to have come of it. In the meantime, the capacity of
:an average hard drive has
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Right now I tend to use:
-b 16384 -f 4096 -c 159
I know you're pretty busy, but any chance of getting this into
sysinstall? Maybe hindged on the size of the partition?
sysinstall supports you changing the args to newfs, it has
* Poul-Henning Kamp [EMAIL PROTECTED] [001207 00:25] wrote:
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Right now I tend to use:
-b 16384 -f 4096 -c 159
I know you're pretty busy, but any chance of getting this into
sysinstall? Maybe hindged on the size of the
Could anyone enlighten me on how to set the amount of shared memory?
I'd like that info for FreeBSD 2.2.2, 3.x, 4.x
Thanks...
William Carlsson
Second Line Support
Teligent Nordic AB
P.O. Box 213
S-149 21 Nynäshamn
SWEDEN
Telephone:
It would be nice to up the default cylinders/group in sysinstall
for larger partitions (anything over 8GB). I wouldn't up it to
159 as a default, but 32 would be a whole lot better then the
Well, if somebody wants to figure out the best defaults, they're
easily set in
In message [EMAIL PROTECTED], Alfred Perlstein writes:
I'd do it, but I don't really have a grasp on the optimal parameters
to set based on FS size.
So far I don't see any indication here (or elsewhere) that anybody
has that grasp.
I guess that is really a testimony to FFS/UFS's qualites...
Matt Dillon wrote:
One possible fix would be to have the kernel track cache hits and misses
on a file and implement a heuristic from those statistics which is used
to reduce the 'initial page weighting' for pages read-in from the
'generally uncacheable file'. This would
In message [EMAIL PROTECTED], Alfred Perlstein writes:
So far I don't see any indication here (or elsewhere) that anybody
has that grasp.
I guess that is really a testimony to FFS/UFS's qualites...
The main thing is that you significantly reduce your fsck time if
you reduce the number
Matt Dillon wrote:
You may be able to achieve an effect very similar to mlock(), but
runnable by the 'news' user without hacking the kernel, by
writing a quick little C program to mmap() the two smaller history
files and then madvise() the map using MADV_WILLNEED in a loop
If there aren't any patches I might look at adding support for it. Probably
only the serial ports, because that is what I need. I would like some advice
on how to do it though. I had a look at the sio driver and it has support
for a few pci cards, but it looks like they are single serial port
On 6 Dec, Matt Dillon wrote:
:
:OK. In fact my problem was just a printf that allocated a buffer via
:__smakebuf at the very last moment (when all memory was allocated).
:This prevent free() to give back all previous pages up to this one. The
:problem was _not_ in malloc.c.
:
:Anyway, i
Remy Nonnenmacher [EMAIL PROTECTED] writes:
Well, I may think using this solution if it remains portable between
Unixes.
It's perfectly portable, with one small variation - on BSD systems,
you pass -1 instead of a file descriptor, while on SysV systems, you
pass a descriptor to /dev/zero (or
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Remy Nonnenmacher [EMAIL PROTECTED] writes:
Well, I may think using this solution if it remains portable between
Unixes.
It's perfectly portable, with one small variation - on BSD systems,
you pass -1 instead of a file descriptor, while on SysV
Matt Dillon [EMAIL PROTECTED] wrote:
The default filesystem parameters are:
newfs -f 1024 -b 8192 -i 8192 -c 16 ...
-i 4096
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
In message [EMAIL PROTECTED], Remy Nonnenmacher wr
ites:
Well, I may think using this solution if it remains portable between
Unixes. I finally tracked down the problem, after suppressing the
reason to call __smakebuf and tooling malloc.c.
Please examine the 'H' option to malloc. This does a
I've mount Win2k share, and for some reason there were read_error that cause
REBOOT on my box.
--
Dimitar Peikov
Programmer Analyst
"We Build e-Business"
RILA Solutions
27 Building, Acad.G.Bonchev Str.
1113 Sofia, Bulgaria
phone: (+359 2) 9797320
phone: (+359 2) 9797300
fax: (+359
On 7 Dec, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Remy Nonnenmacher wr
ites:
Well, I may think using this solution if it remains portable between
Unixes. I finally tracked down the problem, after suppressing the
reason to call __smakebuf and tooling malloc.c.
Please examine
Please examine the 'H' option to malloc. This does a much better
job.
I agree about the hints, but as i said at the end of my previous mail,
this is hardly a clean-bill winning response against a customer
sighting a 30/40 Mbytes 'top' column ;).
Top is not a very good indicator of memory
On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote:
I'd love to do that, but am not quite sure how I'd go about it.
If you read the l-k mailing list, you'll see Linus calling kqueue
"overengineered", and what he is proposing is something that is
definitely not well thought out.
No answer from the -questions list, so I figured I'd try here.
I'm encountering difficulties booting from a 250MB Iomega ZIP drive. The ZIP drive is installed as the primary master IDE. There's a UFS filesystem on /dev/afd0a.
At the boot prompt, I enter
boot: 0:ad(0,a)kernel
afd0? is of
In local.freebsd.hackers you write:
Could anyone enlighten me on how to set the amount of shared memory?
If you mean the wretched System V IPCs, the parameters are in LINT.
Search for "SHM".
I'd like that info for FreeBSD 2.2.2, 3.x, 4.x
The parameters only have descriptive comments in 4.2,
:
:Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
: Remy Nonnenmacher [EMAIL PROTECTED] writes:
: Well, I may think using this solution if it remains portable between
: Unixes.
: It's perfectly portable, with one small variation - on BSD systems,
: you pass -1 instead of a file descriptor,
On Wed, Dec 06, 2000 at 09:50:55AM +0100, Dag-Erling Smorgrav wrote:
"G. Adam Stanislav" [EMAIL PROTECTED] writes:
On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote:
The second and third sentences of the second paragraph (the one that
starts on line 23), as well as the
:
:Matt Dillon wrote:
:
: You may be able to achieve an effect very similar to mlock(), but
: runnable by the 'news' user without hacking the kernel, by
: writing a quick little C program to mmap() the two smaller history
: files and then madvise() the map using MADV_WILLNEED in
In message [EMAIL PROTECTED] Matt Dillon writes:
: : -b 16384 -f 4096 -c 159
: I think Bruce swears by 4K (page-sized) fragments. Not a bad
: way to go. I use 2K because I (and others) put in so much hard work
: to fix all the little niggling bugs in the VM system related to
Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a
stable or current), but I failed:
# make
Warning: Object directory not changed from original
/usr/src/gnu/usr.bin/binutils/gdb
cc: ../libbfd/libbfd.a: No such file or directory
cc: ../libopcodes/libopcodes.a: No such file
On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote:
Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a
stable or current), but I failed:
# make
Warning: Object directory not changed from original
/usr/src/gnu/usr.bin/binutils/gdb
cc: ../libbfd/libbfd.a: No
:
:In message [EMAIL PROTECTED] Matt Dillon writes:
:: :-b 16384 -f 4096 -c 159
:: I think Bruce swears by 4K (page-sized) fragments. Not a bad
:: way to go. I use 2K because I (and others) put in so much hard work
:: to fix all the little niggling bugs in the VM system related
In message [EMAIL PROTECTED] Mike Smith writes:
: If there aren't any patches I might look at adding support for it. Probably
: only the serial ports, because that is what I need. I would like some advice
: on how to do it though. I had a look at the sio driver and it has support
: for a few
Your patch works for me on FreeBSD 4.2-Release. Thanks.
-Zhihui
On Thu, 7 Dec 2000, Brian Dean wrote:
On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote:
Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a
stable or current), but I failed:
# make
This is a interesting topic (to me, anyway), and is one of the things that
often gets overlooked by those of us with less experience. Rather than
getting into a long discussion about modifying the newfs defaults across
the board, what if the newfs options used were based on the size of
the FS?
Hi Hackers,
I'm wondering about two things, how does the kernel detect that a
user logs on a tty, and what should I know if I was to write a kernel
module that detects it (And does something about it)? Must I
read the TCP in-packets for port 23 and detect if a user logged on?
I'm pretty unsure
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Mike Smith writes:
: If there aren't any patches I might look at adding support for it. Probably
: only the serial ports, because that is what I need. I would like some advice
: on how to do it though. I had a look
In message 92918.976225307@critter Poul-Henning Kamp writes:
: There is a PR already with a patch for some multiport cards...
Yes. I'm aware of that patch... But I don't like it because it
doesn't use the multiio pseudo-bus thing that I talked about. Bruce
also has some style concerns with it
We are about to begin a little project that has the following requiremnet.
Perform IP packet filtering in the following way :
i) look at an ip packet header. If some conditions are met let the packet pass
otherwise reject the packet.
ii) Look at ip packet headers of established
As I recall, Matthew Jacob wrote:
Agreed. Thanks for spotting this, Andrew.
No, we should not let users read PCI registers in such a fashion that
will cauase the system to crash.
Ok, I guess just because it's the holiday season, I feel like
opening a can of worms.
I thought the space
How frequently do people fsck?
-- TJ
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message [EMAIL PROTECTED] "Chad R. Larson" writes:
: Has the core group ever weighed in on this? Does the BSDi merger
: change any of the FreeBSD focus with regard to other hardware
: architectures?
Core, per se, hasn't. There's a very strong history in this project
that if a port is
(Hurm Wintendo outperforming unix???!?? Something's
improper about this, and it ought to be fixed... :-)
Comments? Other OS numbers: more recent
FreeBSD versions? Solaris? Tru64? Optimization
patches? Can those OO MSDN lobotomies actually
be good things? Hurm... The Italian
* Dragos Ruiu [EMAIL PROTECTED] [001207 21:18] wrote:
(Hurm Wintendo outperforming unix???!?? Something's
improper about this, and it ought to be fixed... :-)
Comments? Other OS numbers: more recent
FreeBSD versions? Solaris? Tru64? Optimization
patches? Can those OO MSDN
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
Looking at the data I would guess that they
are appending to a file using write()'s on a packet-by-packet basis
Unlikely, given that they're using "tcpdump", which, with the "-w" flag,
writes using standard I/O, and doesn't
On Thu, Dec 07, 2000 at 09:06:04PM -0800, Dragos Ruiu wrote:
(Hurm Wintendo outperforming unix???!?? Something's
improper about this, and it ought to be fixed... :-)
Comments? Other OS numbers: more recent
FreeBSD versions? Solaris? Tru64? Optimization
patches?
As an
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
Looking at the data I would guess that they
are appending to a file using write()'s on a packet-by-packet basis
Or, as per my other mail, perhaps using, on Windows, a version of the
standard I/O library that does bigger
On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote:
It amounts to the same thing, since -w does nothing more then an
fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't
even double buffered.
But I think the last poster had it right... if the bpf
At 16:02 -0800 12/7/00, Jim Browne wrote:
When TFTP tries to open a file, it is expecting struct open_file
member f_devdata to be a pointer to a socket number. When currdev
is "pxe", that assumption is correct. When currdev is "disk*", that
assumption is incorrect. Specifically, tftp.c
This is probably an OK workaround. I think that there's something
fundamentally wrong with the 'net' filesystems getting called for an open
against a disk device, but I've paged out all the libstand state and I
can't get it back fast enough to comment more usefully. 8(
BTW Jim, the stuff
At 17:44 -0800 12/7/00, Mike Smith wrote:
This is probably an OK workaround. I think that there's something
fundamentally wrong with the 'net' filesystems getting called for an open
against a disk device, but I've paged out all the libstand state and I
can't get it back fast enough to comment
Regardless, the check I added should be there as it was an uncovered
error condition.
... and I just realised I deleted your patch. D'oh!
BTW Jim, the stuff you're working on sounds really cool. Thanks for
taking it on!
Apparently I am a glutton for punishment. Expect more bugfix
:I've already looked at this, investigating a problem reported in
:connection with PR 21559. I'll probably sort it out in the next day
:or two, unless someone else gets there first.
:
:--
:Robert Nordier
:
:[EMAIL PROTECTED]
:[EMAIL PROTECTED]
That'd be great. When you have a patch, if
Matt Dillon wrote:
I sure would appreciate it if one of the bootstrap gurus could take
a look at what happens when the tftp open routine is called from a
normal disk-based /boot/loader!
I've already looked at this, investigating a problem reported in
connection with PR 21559.
At 00:13 -0800 12/7/00, Mike Smith wrote:
The option works wonderfully for /boot/pxeboot. But it turns out
that the normal /boot/loader, when compiled with the above
option, will crash horribly whenever it tries to open() a file and
can't find it in the UFS filesystem on
On 08-Dec-00 Jim Browne wrote:
At 16:02 -0800 12/7/00, Jim Browne wrote:
When TFTP tries to open a file, it is expecting struct open_file
member f_devdata to be a pointer to a socket number. When currdev
is "pxe", that assumption is correct. When currdev is "disk*", that
assumption is
55 matches
Mail list logo
