Cardbus and FXP
I asked on -mobile, but didn't get an answer, so now I'm asking here. I Have a Dell Latitude CPiR, and am thinking about getting the Intel cardbus 82559 based ethercard for this machine. What I want to know is, once cardbus is rolled into 3.x, or when 4.x is fianlly release, will the FXP driver be rolled into the cardbus framework for support of this card? I really don't want to buy the 3c589c just for ether on this box, I prefer the intel cards, and am willing to wait. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cardbus and FXP
-On [19991122 14:15], Jamie Bowden ([EMAIL PROTECTED]) wrote: I asked on -mobile, but didn't get an answer, so now I'm asking here. I Have a Dell Latitude CPiR, and am thinking about getting the Intel cardbus 82559 based ethercard for this machine. What I want to know is, once cardbus is rolled into 3.x, or when 4.x is fianlly release, will the FXP driver be rolled into the cardbus framework for support of this card? I really don't want to buy the 3c589c just for ether on this box, I prefer the intel cards, and am willing to wait. Considering the amount of work Warner(imp) still has to do on the cardbus support I sincerely doubt he will be able to get it done for 4.0. Work IS underway though. And when the support is there, adding drivers into that framework shouldn't be a problem. But that's my idea/opinion and I may be totally off here. Cheers, -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / Tel: +31 - (0) 10 - 240 39 70 VIA NET.WORKS Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel building and more
Hi to all! I am new to FreeBSD. I was on Linux, and with great help of my friend Alex I got on FreeBSD. I have several questions: 1) how can I build my kernel that he can recognize my modem...Kernel show that hi is testing COM3 but he cannot find there...2) my sound card is PnP and kernel found her on PnP devices...how can I use her...how can I test her...3) where I can find some books about Linux kernel...I did some project about detecting memory errors and want to test it on BSD kernel...4) who is doing upgrade of kernel and if there is any chance if I can send some my suggestions...that is all folks for now... Regards, Milos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel building and more
-On [19991122 15:40], Milos Puzovic ([EMAIL PROTECTED]) wrote: Hi to all! I am new to FreeBSD. I was on Linux, and with great help of my friend Alex I got on FreeBSD. I have several questions: 1) how can I build my kernel that he can recognize my modem...Kernel show that hi is testing COM3 but he cannot find there... http://www.freebsd.org/handbook/kernelconfig.html 2) my sound card is PnP and kernel found her on PnP devices...how can I use her...how can I test her... controller pnp0 device pcm0 3) where I can find some books about Linux kernel...I did some project about detecting memory errors and want to test it on BSD kernel... About Linux kernel? No idea. The BSD kernel is detailed in /usr/src/sys and the Design and Implementation of 4.4 BSD. I am also in the LONG prospect of writing this documentation for the FreeBSD project. 4) who is doing upgrade of kernel and if there is any chance if I can send some my suggestions...that is all folks for now... [EMAIL PROTECTED] is generally one of the lists which occupies itself with kernel ideas. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / Tel: +31 - (0) 10 - 240 39 70 VIA NET.WORKS Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ANNOUNCE: SPY-0.1 - syscalls monitor
Hi, SPY allows you to monitor and/or selectively block syscalls on your system. It could be used either as a safety monitoring device, policy enforcement, or debugging tool. You can download the sources (NOTE: -current only) from: http://www.freebsd.org/~abial/spy-0.1.tgz Excerpt of README follows: - This kernel module allows you to selectivly monitor and/or disable execution of system calls (syscalls) on your system, and log detailed info to syslog service. It's sometimes desirable to monitor selected syscalls for security reasons, or for debugging. For example, many security holes are related to setuid/setgid programs. You can monitor and log all attempts to use these syscalls. You can also disable certain syscalls altogether, if you really know what you're doing... Already existing tools (like ktrace(1) or truss(1)) can provide much more detailed information, but they are more fit to tracing single processes or process groups, and not setting overall system policy (speaking of which: this module is an example of very primitive auditing and policy enforcing device). Features Using SPY module you can set up your system to: * log detailed info on execution of any selected syscall. In case of a few most important ones, there are specific handlers to log also the arguments of the syscall in understandable format. They are as follows: execve, set*id, chdir, open, link, unlink, chmod, chown, mkdir, rmdir (You are welcome to add others :-) Any syscall can be monitored, but in general case its arguments cannot be interpreted. * set kind of information to be logged. You can restrict logging on a per syscall basis, with the following constraints (OR-ed): - uid or gid - superuser only - all users except superuser - combination of the above You can also adjust level of logging on a per syscall basis. There are three levels available: - basic: logs minimum information sufficient to identify the syscall and process owner - arg: logs also the arguments of the syscall, if possible - full: logs all information available. * disable selected syscalls, which prevents specified categories of users to use them at all, and any such attempt is logged. By default the SPY module logs attempts to use execve syscall by root owned processes, and setuid/setgid by any user owned process. Default mode for other syscalls, used when you add them to monitoring, is to log all uses with all arguments. - Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmpfw in pine via NFS
Daniel /me shivers at the thought of my (easily) 500+ new messages a day Daniel and hundreds of thousands of messages being stored one file for each Daniel message... Works OK for us (and a number of even larger ISPs using Maildirs). Though we use NetApps for the file storage and they have a much better system for storing large numbers of files in a directory, so it doesn't get quadratically slower. Largest single FS we have at the moment has about 3.5 million files in it; I don't know what the largest number of files in a single directory is, but I've seen 10s of thousands on occasion without problems. It works much better than a large file per user and NFS file locking, which makes me shiver. -- Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
On Sun, 21 Nov 1999, Jordan K. Hubbard wrote: Bringing something into question without detail is useless. If I seriously questioned your sexual orientation, for example, you'd have every right to ask me just what the hell I was basing such a question on and why I was uncertain about it in the first place. Dennis has no less of an obligation to define his terms and not simply wave his hands. And besides, you need to read his message again - he DID make a claim about performance, he said it was slower than 2.2.x. That by itself, unfortunately, means precisely nothing. In my tests, I've found that FreeBSD is getting faster with successive releases -- I think because the increased weight of the extra disks helps overcome wind resistance. HTH, HAND. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cardbus and FXP
In message [EMAIL PROTECTED] Jamie Bowden writes: : : I asked on -mobile, but didn't get an answer, so now I'm asking here. I : Have a Dell Latitude CPiR, and am thinking about getting the Intel cardbus : 82559 based ethercard for this machine. What I want to know is, once : cardbus is rolled into 3.x, or when 4.x is fianlly release, will the FXP : driver be rolled into the cardbus framework for support of this card? : : I really don't want to buy the 3c589c just for ether on this box, I prefer : the intel cards, and am willing to wait. cardbus in 3.x likely isn't going to happen. Cardbus in 4.x is being worked on, or at least the groundwork for it is being worked. fxp is one of the drivers that I have in mind to make work with cardbus. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
In message [EMAIL PROTECTED] Ben Rosengart writes: : In my tests, I've found that FreeBSD is getting faster with successive : releases -- I think because the increased weight of the extra disks helps : overcome wind resistance. That's just due to the beefier system requirements. of course the disks are going to weigh more. they have more 1's on them than before :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmpfw in pine via NFS
On Mon, 22 Nov 1999, Alan Judge wrote: Daniel /me shivers at the thought of my (easily) 500+ new messages a day Daniel and hundreds of thousands of messages being stored one file for each Daniel message... Works OK for us (and a number of even larger ISPs using Maildirs). Though we use NetApps for the file storage and they have a much better system for storing large numbers of files in a directory, so it doesn't get quadratically slower. Largest single FS we have at the moment has about 3.5 million files in it; I don't know what the largest number of files in a single directory is, but I've seen 10s of thousands on occasion without problems. It works much better than a large file per user and NFS file locking, which makes me shiver. I agree that the one-file-per-message things scales fine--I have a fairly dinky 486 w/24mb of RAM running my cyrus server, and it does just fine with a lot of files for a fair number of messages: Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on /dev/wd1s1g 31699945502 24613816%7224 69574 9% /usr/var/spool/imap2 /dev/wd1s1f 496367 163672 29298636% 27949 94929 23% /usr/var/spool/imap /dev/wd2s1e 19403838 838047 17013484 5% 179066 4513412 4% /usr/var/spool/imap3 In fact, the whole thing scales a *lot* better than a single file per folder, as a lot less time is spent seeking through large mailfiles looking for arbitrarily located string boundaries, scanning through attachments, etc. I'm about to upgrade my cyrus server, but not because of performance problems :-). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
A file with holes - a bug?
Please take a look at the following piece of code that creates a large
hole in a file named hole.dat. It tries to write 0x30-0x39 both at the
front and the tail of that file, the hole is therefore in the middle.
main()
{
char c;
FILE * fp;
fp = fopen("hole.dat", "w");
for (c=0x30; c0x3a; c++) fputc(c, fp);
fputc('\n',fp);
fflush(fp); /* XXX */
lseek(fileno(fp), 3 * 8192, SEEK_CUR);
for (c=0x30; c0x3a; c++) fputc(c, fp);
fputc('\n',fp);
fclose(fp);
}
If I remove the fflush(fp), then the characters 0x30-0x39 will be all
written at the end of the file (use hexdump to find out), not as expected
(one at the beginning and the other at the end). It seems to me that the
first for loop happens AFTER the lseek() statement without fflush(). Can
anyone explain this to me? I am using FreeBSD 3.3-Release.
By the way, I also find out if you copy a file with holes into another
file, the holes in the first file will be replaced with 0s in the second
file, taking more disk space (check with du). Is there a better solution
for this?
Any help is appreciated.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A file with holes - a bug?
On Mon, 22 Nov 1999, Zhihui Zhang wrote: lseek(fileno(fp), 3 * 8192, SEEK_CUR); don't mix things that use file descriptors with stdio. End of problem. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ok, that's it, enough is enough! (rpc.lockd)
Ok... I have *had* it with the meta, but not really, lockd. Are there any kernel issues with correctly implimenting rpc.lockd?How can I take a filehandle and map it into a filename, with path, so I may open it and lock it on the server? Are there any protocol specs? I downloaded the RFC for version 4 nlm (which we do not supoprt at *all*), but it only lists diffs to the version 3 spec, which I cannot find, and the source is not a whole lot of help on this issue. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A file with holes - a bug?
On Mon, Nov 22, 1999, Zhihui Zhang wrote: lseek(fileno(fp), 3 * 8192, SEEK_CUR); If I remove the fflush(fp), then the characters 0x30-0x39 will be all written at the end of the file (use hexdump to find out), not as expected (one at the beginning and the other at the end). It seems to me that the first for loop happens AFTER the lseek() statement without fflush(). Can anyone explain this to me? I am using FreeBSD 3.3-Release. That line (as quoted) where you use lseek is broken. Use fseek instead. Use only one method to access files. Either stdio or the open/read/write syscalls. -- |Chris Costello [EMAIL PROTECTED] |If a group of N persons implements a COBOL compiler, there will be N-1 |passes. Someone in the group has to be the manager.-- T. Cheatham `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
On Mon, 22 Nov 1999, David E. Cross wrote: Ok... I have *had* it with the meta, but not really, lockd. Are there any kernel issues with correctly implimenting rpc.lockd?How can I take a filehandle and map it into a filename, with path, so I may open it and lock it on the server? Are there any protocol specs? I downloaded the RFC for version 4 nlm (which we do not supoprt at *all*), but it only lists diffs to the version 3 spec, which I cannot find, and the source is not a whole lot of help on this issue. here's a url to some of the stuff I have in the works before work utterly consumed me: http://www.freebsd.org/~alfred/misc-patches/ (lockd.diff) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A file with holes - a bug?
On Mon, Nov 22, 1999 at 01:48:38PM -0500, Zhihui Zhang wrote: By the way, I also find out if you copy a file with holes into another file, the holes in the first file will be replaced with 0s in the second file, taking more disk space (check with du). Is there a better solution for this? Unfortunately, not one that preserves the holes exactly the way they existed in the original file. See http://reality.sgi.com/zwicky_neu/testdump.doc.html for a good discussion of the problems of copying files with holes via the userland interface to the file system. If all you care about is the space, you could write a version of cp that compressed all zeroed blocks into holes. -- Brooks -- "Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one" --Thomas Jefferson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
Actually I wrote a system call for opening a file given a file handle for freebsd a while back (oh, gee, has it really been 5 years ...), as part of mnfs i'll try to find it. You don't need to map it to a filename to make it go. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Is there any xDSL driver been supported for FreeBSD?
or other BSD platforms? Any pointers are excellent. ps. I understand that most of the DSL modems/routers using ethernet or ATM as the interface talking to the host. However, I'm asking about the internal DSL modem that need DSL driver. Robert __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
On Mon, 22 Nov 1999, Ronald G. Minnich wrote: Actually I wrote a system call for opening a file given a file handle for freebsd a while back (oh, gee, has it really been 5 years ...), as part of mnfs i'll try to find it. You don't need to map it to a filename to make it go. i forgot to include that in my last email, the syscall is availble in -current for some time now. I brought fhopen, fhstat, and fhstatfs all over from NetBSD several months ago. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
Does NetBSD have a working rpc.lockd... that would make this much easier. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
On Mon, 22 Nov 1999, David E. Cross wrote: Does NetBSD have a working rpc.lockd... that would make this much easier. at a glance at http://cvsweb.netbsd.org/... no. Linux may have one, a temporary GPL'd port would be interesting perhaps. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
wacky rpc.lockd idea...
I've noticed about 99% of the panics on our machines are the result of NFS, more often than not it is the result of a backing store file being blown away underneath the client. ie. person editing a file on one machine, compiling and running on a second, then removing the binary on the first machine. If we had a working lock manager could we not have the kernel open a shared lock on anything it had in backing store, would that not assure that files didn't go poof in the night? -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE offer.
"Julian" == Julian Elischer [EMAIL PROTECTED] writes: Julian (the other end was a 486DX50 :-) with enough RAM we could Julian probably serve 10K sessions, though that would require 10K ppp Julian daemons until we got the kernel bypass working. in either Julian case it would presently leave a HUGE ifconfig -a output as Julian there would be 1 intefeaces, each representing a channel Julian to a client. It migh tbe worth wondering if we need to Julian abstract a 'class of PVCs' type device that feeds to some othe Julian rway of splitting them. (we can do this with netgraph pretty Julian easily.) (is it worth doing?) I'd be willing to fund that experiment. It's possible we should meet either virtually or in person. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip checksum
On Tue, 23 Nov 1999, Parthasarathy M. Aji wrote: !Hey, ! !I am trying to recompute the checksum of an IP packet. I use !netinet/in_chksum.c to do this. The values returned are not correct. I've !reset the ip_sum field to 0 before doing the sum. Is there something !missing? ! !thanks ! ! Would you be able to provide some code to illustrate the situation? There are several things that may go wrong. What exactly are you trying to do here? (You may be using the wrong procedure) and what are you getting for return values? --Bosko -- Bosko Milekic [EMAIL PROTECTED] "I want now to tell you, gentlemen, whether you care to hear it or not, why I could not even become an insect." --F. Dostoyevski To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip checksum
How many bytes have you changed?
is it possible that some of the values have already been ntohs()'d
or something similar?
rather than recalculate the whole packet, just update the exisitng
value.
there is an rfc for this but it took me a while to get
the code right in C on a 386. The trick is getting the 1s complement
arithmetic right.
#define FIXSUM16(c, op, np) \
do {\
(c) -= (u_int16_t) ~*((u_int16_t *) (op));\
if ((c) 0) {\
(c) += 0x; \
} \
(c) -= (u_int16_t) *((u_int16_t *) (np));\
if ((c) 0) {\
(c) += 0x; \
} \
} while (0)
/*
* IpsumReplaceShort()
*
* Replace a 16 bit aligned (relative to the checksum) 16 bit value
* in a packet and change the IP/TCP/UDP checksum at the same time.
*
* Works with both big and little endian machines(!)
*
* If for some wierd reason you want to replace a nonaligned value,
* you need to byteswap it and the old value before doing the
* subtractions.
*/
void
IpsumReplaceShort(u_int16_t *cksump, u_int16_t *oldvalp, u_int16_t newval)
{
register int cksum;
cksum = *cksump;
FIXSUM16(cksum, oldvalp, newval);
*cksump = cksum;
*oldvalp = newval;
}
On Tue, 23 Nov 1999, Parthasarathy M. Aji wrote:
Hey,
I am trying to recompute the checksum of an IP packet. I use
netinet/in_chksum.c to do this. The values returned are not correct. I've
reset the ip_sum field to 0 before doing the sum. Is there something
missing?
thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
On Fri, 8 Oct 1999, Matthew Dillon wrote: : : Adjusting the bytes-per-inode (-i) specification in newfs should not : pose a problem. : :IOW now you say it's ok to use very high values of -i... ;-) : :Andrzej Bialecki No, I didn't say that. My recommended maximum is still 262144. Fsck should be reasonably fast with that number and the filesystem should still be able to maintain reasonable efficiency. Ok, I can live with that, I guess. Thanks a lot for your help! What's the recommended way to reduce the number of cylinder groups a bit? -c's maximum limit is affected by combinations of -b and -i, possibly some others. PHK was talking about new, more sensible values for filesystem parameters, but I don't know what happened. I just think it's a bit silly to go generating hundreds of cg's for a 34GB unit... and this _with_ the max -c setting of 26 (for this fs). /dev/vinum/rn8: 63700992 sectors in 15552 cylinders of 1 tracks, 4096 sectors 31104.0MB in 599 cyl groups (26 c/g, 52.00MB/g, 256 i/g) super-block backups (for fsck -b #) at: 32, 106528, 213024, 319520, 426016, 532512, 639008, 745504, 852000, 958496, ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
:What's the recommended way to reduce the number of cylinder groups a bit? :-c's maximum limit is affected by combinations of -b and -i, possibly some :others. PHK was talking about new, more sensible values for filesystem :parameters, but I don't know what happened. I just think it's a bit silly :to go generating hundreds of cg's for a 34GB unit... and this _with_ the :max -c setting of 26 (for this fs). : :/dev/vinum/rn8: 63700992 sectors in 15552 cylinders of 1 tracks, 4096 sectors :31104.0MB in 599 cyl groups (26 c/g, 52.00MB/g, 256 i/g) :super-block backups (for fsck -b #) at: : 32, 106528, 213024, 319520, 426016, 532512, 639008, 745504, 852000, 958496, : :... Joe : :--- :Joe Greco - Systems Administrator[EMAIL PROTECTED] Well, -i doesn't effect c/g any where near as much as -b does. Try bumping the block size up to 16K and use '-c 999' and see what newfs tells you the max c/g is. -b 16384 -f 2048 -c 999. On my test it let me do 89 c/g. As we already know, non-standard block sizes will create problems under stable and may create them under current. I believe I have fixed the bugs under current (in getnewbuf()) but since no comprehensive testing has been done you still have a lockup risk. Work on the VM system mainly by Luoqi a few months ago fixed the buffer corruption bugs, so only lockup bugs should be left. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
