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.
:>
:> 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 i
: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 inc
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,
* 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
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: +46
> 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 sysinstal
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...
* Poul-Henning Kamp <[EMAIL PROTECTED]> [001207 00:52] wrote:
> 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
>
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 redu
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 lo
> 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 p
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.
> :
> :Anywa
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 (o
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, whi
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 PROTECTE
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
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.
>
> Pl
>> 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
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 descri
Er, I obviously meant 'not use mmap' in that last posting. I'm sure
that first sentence was confusing :-)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
: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.
:
:What happens is that malloc() uses the pages to store pginfo chains. If
:all memory is used, it allocates hig
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
:
: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_WILLNEE
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 pa
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 or
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/lib
:
: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 relate
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
In the last episode (Dec 07), Matt Dillon said:
> Well, too-large a C/G will result in greater file fragmentation,
> because FFS can't manage the file layouts in the cylinder groups as
> well. The default of 16 is definitely too little. 100+ is probably
> too much. Something in the middle will
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? T
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 ab
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 h
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 i
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 conn
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 suppo
(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 gauntlet
* 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 MS
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 experi
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 writ
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 d
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 you
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 bug
: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 you
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 2155
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 filesys
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
59 matches
Mail list logo