[vox-tech] submitting a kernel patch
So I've got a really dead simple kernel patch that adds the device ID for my ATEN UC-110T USB ethernet dongle[1] to the pegasus driver, so that the driver will cause the adapter to work. To whom do I submit the patch? And how rigorously do I need to test it? I've already verified that I can ssh files across it and browse the web on it. (Patch attached - it's really trivial) --Ken Bloom [1] So I can do ethernet with my new old laptop. Thanks Eirik! -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. uc110t.patch Description: Binary data pgpPvNYFk2QLU.pgp Description: PGP signature ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] BASH: ignore space in for loop
Dylan Beaudette wrote: The "Name of place" values often have spaces in them, which seems to be confusing a for loop in bash: running: for this_quadname in `cat file_a`; do echo grep -i "$this_quadname" file_b ; done while read pattern do grep -i "$pattern" file_b done < file_a or cat file_a | while read pattern do grep -i "$pattern" file_b done PS I am merely trying to implement a simple many-to-one join on 2 text files based on a common key, which is the first column in each file... however the spaces in the keys are messing up the conventional 'join' program... You should be able to specify the field separator using join's -t option...? ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] BASH: ignore space in for loop
On Wed, 20 Oct 2004, Dylan Beaudette wrote: > Hi -- > > Can't seem to figure out how to make this BASH script do what I would like it > to do: > > I have 2 files: > > file A: > Name of place 1 > Name of place 2 > ... > > file B: > Name of place 1 [tab] code1 > Name of place 1 [tab] code1 > ... > > The "Name of place" values often have spaces in them, which seems to be > confusing a for loop in bash: > > running: > for this_quadname in `cat file_a`; do echo grep -i "$this_quadname" file_b ; > done > > produces this: > grep -i 'Name' file_b > grep -i 'of' file_b > grep -i 'place' file_b > > ...so it would seem that the for loop is iterating over both spaces AND > newlines in the `cat file_a` expression... Hi, Try using a while-read loop instead: while read line; do grep "$line" test2.txt; done < test.txt Or in your case: while read this_quadname; do echo grep -i "$this_quadname" file_b ; done < file_a LMK if it works! HTH, FL ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] BASH: ignore space in for loop
Hi -- Can't seem to figure out how to make this BASH script do what I would like it to do: I have 2 files: file A: Name of place 1 Name of place 2 ... file B: Name of place 1 [tab] code1 Name of place 1 [tab] code1 ... The "Name of place" values often have spaces in them, which seems to be confusing a for loop in bash: running: for this_quadname in `cat file_a`; do echo grep -i "$this_quadname" file_b ; done produces this: grep -i 'Name' file_b grep -i 'of' file_b grep -i 'place' file_b ...so it would seem that the for loop is iterating over both spaces AND newlines in the `cat file_a` expression... is there any way to make bash only iterate over the newline characters? thanks in advance for any ideas! PS I am merely trying to implement a simple many-to-one join on 2 text files based on a common key, which is the first column in each file... however the spaces in the keys are messing up the conventional 'join' program... Dylan ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] RAID systems
--- Bill Broadley <[EMAIL PROTECTED]> wrote: > > > Measuring a real world workload in real world conditions. Short > > > of that I'd recommend bonnie++ and "PostMark: A New File System > > > Benchmark" > > > > Right now all I have been doing is cron'ing iostat to give me > snapshots > > every few minutes. > > Very reasonable. Although thats a snapshot. iostat 60 or iostat 600 > will give you a more complete picture (24/7 totals instead of > occasional > snapshots). Again, thanks for the great tip. > > > Yea, the worst is always what I plan for with these sorts of > things, > > but I guess no system is foolproof or failsafe. > > Indeed, but offsite offline backups are a great place to start. I'll be talking to my boss about this today. > > > The best idea I have of the population of files that will be stored > is: > > random. I have general statistics, but they can change on even a > > daily basis. Most of the storage would be for millions of <64k > text > > files, but not always. > > I like to run something like: > http://broadley.org/bill/dirstat.pl > > [EMAIL PROTECTED] perl]# time ./dirstat.pl / > scanning / > > Total directories =25807 > Total files = 389283 > Total size=98441.5 MB > Average Directory = 15.1 files and 3906.08 KB > Maximum Directory = 7522 files //dev > Average filesize = 258.95 KB > > real0m21.077s > user0m5.128s > sys 0m10.775s > [EMAIL PROTECTED] perl]# > > So things to look for: > * large directories might need application changes for smaller dirs, > ext3 htrees, reiserfs or other support for large dirs. > * average file size (for inode allocation) > Pretty handy little tool there. > > > I believe ext3 will allocate additional inodes as needed, no need > to > > > preallocate. > > > > > > > One of the previous raid systems (scsi hardware raid) that we had > ran > > out of inodes (it was formatted ufs and ran in solaris) in the > first > > month or two that we used it for production. I just don't want to > make > > the same mistake twice... > > Ugh, indeed, I must have misremember or maybe remembering for the > wrong > filesystem. Never allocate more than one inode per block though, > they will go to waste. > > > As mentioned before, pretty randomized populations, and there's a > high > > degree of variance between projects. Basically, we are sent huge > > populations of data, we process the data into different formats, > and > > return it. The input data are mostly correspondance (email, word > docs, > > spreadsheets, etc), but that is generally just a rule of thumb... > The > > populations are simply moving targets that vary widely from each > > project, and that is all that I have to go on... :) > > If you are ever stuck with a lack of inodes you can make a filesystem > in a > file and loop mount it. Just make sure that you have one free inode to make the file... > > > For some projects, there can be 3 million files where 99% are less > than > > 4k in size. For others there can be 3000 files where all are more > than > > mkfs.ext3 -T news will make one inode per 4kb block. Exactly the option I used, I must have forgotten to post that. Actually, as i recall, it was: [EMAIL PROTECTED] /]# mkfs.ext3 -b 4096 -R stride=16 -T news /dev/md0 > > > 128k. Most fall somewhere in between. Knowing exact numbers would > > mean that I could tell the future and know what would be coming in > the > > door (which would be cool...). > > Heh. > > > Again, here is my dilemma. I just chose something that would > hopefully > > e "good enough(tm)" to use everyday, and something that would > handle 30 > > gazillion 2k files (I for-sure know there will be gazillions of > emails, > > most of which are less than 2k, what I don't know is the ratio of > > smaller files to larger files). > > Files smaller than blocksize aren't coalesced afaik, you might need > another fs if you need it, on the otherhand you can set 1k or 2k > blocks. For some cases, I might think about reducing the block size, but for now, I am just going to sit with 4k blocks until there is a good reason to move to a smaller size. Even before I think of reducing block sizes, I might think about trying reiserfs if the performance for small files isn't great. I might be building a few more of these boxes soon, so that is one thing I am still going to try out. I think I'll try it out just to get a comparison between the two fs's. > > > I have a triple supply on the drive cabinet and a double supply on > the > > box, all fed by UPS. > > Nice. > Thanks for all the help and advice, Bill. I humbly bow to your wise words :) --thanks much jan > -- > Bill Broadley > Computational Science and Engineering > UC Davis > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech > = <><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: [vox-tech] cordless mouse question
on Sat, Oct 16, 2004 at 05:31:39PM -0400, Peter Jay Salzman ([EMAIL PROTECTED]) wrote: > Got a Memorex USB cordless optical mouse. Works great with autops2. The > problem is that it appears to be sucking AAA batteries at the rate of 2 every > 1.5 - 2 weeks, which is unacceptable to me. Rechargeables. Peace. -- Karsten M. Self <[EMAIL PROTECTED]>http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete strangers to kill again. - That Movie Guy's synopsis of "The Wizard of Oz" signature.asc Description: Digital signature ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [OT] Gentoo talk!? (was re: [vox-tech] debian and openoffice)
On Monday 18 October 2004 11:23, Bill Kendrick wrote: > On Mon, Oct 18, 2004 at 10:19:31AM -0700, Rod Roark wrote: > > I guess Gentoo is much like Debian in many respects, aside > > from the compile-from-source focus. Anyway I wanted to > > comment that I've been generally pleased with the up-to- > > dateness of the Gentoo's "stable" tree, > > > > So WHEN are we going to have a talk on Gentoo!? :^) > > (We should also have at least a mini-talk on Ubuntu, which seemed > to come out of nowhere and get tons of converts lately. Heck, > a few weeks ago some teenager coming out of a restaurant as I was > going in noticed my Debian shirt and started asking if I had tried it!) > > :) > > -bill! > [EMAIL PROTECTED]New Breed Software > http://www.newbreedsoftware.com/ Tux Paint 0.9.14 is out! > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech I think a gentoo talk would be pretty cool. :) -- [EMAIL PROTECTED] Mike Wenk ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
