I'm trying out the personal version of bru for backinging up some samab shares here. Just wondering who is using it out there an if you did any speed tweaks to increase the speed of backups. I did a test backup this morning of about 1 gig of data an it took 30 minutes to complete it. Based on that time frame the 11 gigs I have in the samba share would take up to 5 hours or so to finish. I did a test with the buffersize at 64k an 128k an it was same amount of time to do the backup in my testing. thanks for any help with this. I'm using a quantum DLT vS80 tape drive. thanks jack
On 12:18 Tue 18 Jan , Jack Malone wrote:
I'm trying out the personal version of bru for backinging up some samab shares here. Just wondering who is using it out there an if you did any speed tweaks to increase the speed of backups. I did a test backup this morning of about 1 gig of data an it took 30 minutes to complete it. Based on that time frame the 11 gigs I have in the samba share would take up to 5 hours or so to finish. I did a test with the buffersize at 64k an 128k an it was same amount of time to do the backup in my testing. thanks for any help with this. I'm using a quantum DLT vS80 tape drive.
thanks
jack
I have used BRU, but it was a long time ago ...like a couple years, I think. That one came w/Caldera Open Linux. I do know that the version I used had no speed tweaks. I backed up to disk, burned to CDs. The 2+/- GB of data I backed up on that particular box took about 1.5 hours, I think. It is a lengthy process no matter what one uses, but lately I have taken to using DAR and like the fact that it'll back up quite rapidly the 5+GB I now have. I have never timed it but know it happens more quickly than you have indicated. FWIW... -- ..."Yogi" CH Namast Yoga Studio
I have used BRU, but it was a long time ago ...like a couple years, I think. That one came w/Caldera Open Linux. I do know that the version I used had no speed tweaks. I backed up to disk, burned to CDs. The 2+/- GB of data I backed up on that particular box took about 1.5 hours, I think. It is a lengthy process no matter what one uses, but lately I have taken to using DAR and like the fact that it'll back up quite rapidly the 5+GB I now have. I have never timed it but know it happens more quickly than you have indicated.
I take it DAR backs up to another hard disk in the system. Correct me if im wrong. That would be good for fast backups an quick restore but hard to take the backsup off site in case of fire. I do a complete backup of the samba share across the network to a windows machine on a hard drive in the system just for that purpose an its quick fast at about 2 hours to backup the 11 gigs an compare them. I need the tape backup for removing the night before's backup off site, aka taking it home with me. Then if the building burns down You have your data off away from the fire an in a safe place. I just copied the 11 gigs off to my test bench machine an fixing to see how long it takes to backup that 11 gigs of stuff with bru now. jack
On Tuesday 18 January 2005 07:21 pm, Jack Malone wrote:
on a hard drive in the system just for that purpose an its quick fast at about 2 hours to backup the 11 gigs an compare them. I need the tape backup for removing the night before's backup off site, aka taking it home with me. Then if the building burns down You have your data off away from the fire an in a safe place. I just copied the 11 gigs off to my test bench machine an fixing to see how long it takes to backup that 11 gigs of stuff with bru now.
some years ago i used Yusuf Nagree's handy 'Taper' program to back up to Iomega Tape Drive, & Mr Nagree, in australia, was most helpful. Now, during the day, i do cron-timed TAR.GZ backups of data files. every second day, backup whole system to other drive/other partitions in rotation. Weekly, do RSYNC backups of whole system to spare HDs, plugged in just for the backup, and then taken off-site. it seems that it takes about 10 minutes to backup 6 gigs. Could someone please be so kind and explain what are the enduring charms of Tape backups? thanks best rgds _________
A
some years ago i used Yusuf Nagree's handy 'Taper' program to back up to Iomega Tape Drive, & Mr Nagree, in australia, was most helpful. Now, during the day, i do cron-timed TAR.GZ backups of data files.
every second day, backup whole system to other drive/other partitions in rotation.
Weekly, do RSYNC backups of whole system to spare HDs, plugged in just for the backup, and then taken off-site.
it seems that it takes about 10 minutes to backup 6 gigs.
Could someone please be so kind and explain what are the enduring charms of Tape backups? Well i do the tape backups to take offsite myself. What type of setup do you have for the inserting an removal of the hd for the backup purpose. Do you shut down the machine to insert an remove them or is this removal a hot removal. thanks for info.
I'm open to any sugestions for backuping up but it needs to be done afterhours so as to make sure to get all files what would be in use during the day. Thanks jack
Well i do the tape backups to take offsite myself. What type of setup do you have for the inserting an removal of the hd for the backup purpose. Do you shut down the machine to insert an remove them or is this removal a hot removal. thanks for info. I bought a 60G 2.5" HD and installed it in a 2.5" USB 2.0 case for
Jack Malone wrote: portable removable off site backup. I made a small script using rsync, and just need to plug it in, run the script, and it is pretty fast and has been working well. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On Tuesday 18 January 2005 08:15 pm, Jack Malone wrote:
What type of setup do you have for the inserting an removal of the hd for the backup purpose. Do you shut down the machine to insert an remove them or is this removal a hot removal. thanks
~ on sundays, for offsite backups, do close down for a few moments, to insert HD, RSYNC, then remove HD. best rgds __________
On Tue, 18 Jan 2005, riccardo wrote:
On Tuesday 18 January 2005 07:21 pm, Jack Malone wrote:
on a hard drive in the system just for that purpose an its quick fast at about 2 hours to backup the 11 gigs an compare them. I need the tape backup for removing the night before's backup off site, aka taking it home with me. Then if the building burns down You have your data off away from the fire an in a safe place. I just copied the 11 gigs off to my test bench machine an fixing to see how long it takes to backup that 11 gigs of stuff with bru now.
some years ago i used Yusuf Nagree's handy 'Taper' program to back up to Iomega Tape Drive, & Mr Nagree, in australia, was most helpful. Now, during the day, i do cron-timed TAR.GZ backups of data files.
every second day, backup whole system to other drive/other partitions in rotation.
Weekly, do RSYNC backups of whole system to spare HDs, plugged in just for the backup, and then taken off-site.
it seems that it takes about 10 minutes to backup 6 gigs.
Could someone please be so kind and explain what are the enduring charms of Tape backups?
DLT tapes can last 25 years, and they don't break if you drop them? Oh,
and I can eject a tape and take it with me very easily? Hard drives are
delicate compared to DLT tapes?
I use disk to disk to tape backups. rsync from (N) hosts to a backup
host and then back /that/ up with tape. rsyncs are daily, disk to tape
is "when I feel like it" because so little changes day to day.
Tape has it's place and it's "long term" storage. "long term" for me is
more than six months to tens of years. Tape, unlike CDs and DVDs,
lasts. At least good tape does. DLT, Super DLT, possibly VXA and
probably Mammoth and LTO. I wouldn't touch DDS (DAT).
I use rsync with --link-dest.
--
Carpe diem - Seize the day.
Carp in denim - There's a fish in my pants!
Jon Nelson
On 13:21 Tue 18 Jan , Jack Malone wrote:
I have used BRU, but it was a long time ago ...like a couple years, I think. That one came w/Caldera Open Linux. I do know that the version I used had no speed tweaks. I backed up to disk, burned to CDs. The 2+/- GB of data I backed up on that particular box took about 1.5 hours, I think. It is a lengthy process no matter what one uses, but lately I have taken to using DAR and like the fact that it'll back up quite rapidly the 5+GB I now have. I have never timed it but know it happens more quickly than you have indicated.
I take it DAR backs up to another hard disk in the system. Correct me if im wrong. That would be good for fast backups an quick restore but hard to take the backsup off site in case of fire. I do a complete backup of the samba share across the network to a windows machine on a hard drive in the system just for that purpose an its quick fast at about 2 hours to backup the 11 gigs an compare them. I need the tape backup for removing the night before's backup off site, aka taking it home with me. Then if the building burns down You have your data off away from the fire an in a safe place. I just copied the 11 gigs off to my test bench machine an fixing to see how long it takes to backup that 11 gigs of stuff with bru now.
jack
I have been doing testing w/various distros and backing up each one for quick reversion, if I wish. In doing so I consistently restore from a samba share on the server. I have also experimented w/backing up to the server vs copying to said server, and had no problems except w/restoring from NFS on Linux. Since regular backups are made via cron on a dialy, weekly, monthly basis they are done at night when the server is down. Consequently, I copy the b/u to the server when I put it back up the next day. I see no reason why this would not work for you, as well, since one can specify the media size --like, for instance, DVD-RW or CD-RW media. That is what DAR is: Disk ARchiver. FWIW, when I was using BRU I consistently backed up the Windows98SE partition so that I had a solid backup. I was using Linux quite a bit butnot totally. When it came down to the nitty-gritty, I put in the floppy disk for rescue boot, formatted the partition w/the copy system files option, went into Linux & chose 'rewrite all' for the recovery. When I booted into Windows98SE it didn't even know it'd ever been off the drive. It was really awesome. The DAR backup does the same thing, only w/the Linux partition. I have also accidentally backed up mounted samba or NFS shares. When one uses the rescue disk, reformats the partitions & does the recovery & boots, the Linux partition is just the way you left it. If you would like a sample script as to how I do this just e-mail me privately & I'll be happy to supply the scripts. HTH... -- ..."Yogi" CH Namast Yoga Studio
On Tuesday 18 January 2005 02:21 pm, Jack Malone wrote:
I take it DAR backs up to another hard disk in the system. Correct me if im wrong. That would be good for fast backups an quick restore but hard to take the backsup off site in case of fire. I do a complete backup of the samba share across the network to a windows machine on a hard drive in the system just for that purpose an its quick fast at about 2 hours to backup the 11 gigs an compare them. I need the tape backup for removing the night before's backup off site, aka taking it home with me. Then if the building burns down You have your data off away from the fire an in a safe place. I just copied the 11 gigs off to my test bench machine an fixing to see how long it takes to backup that 11 gigs of stuff with bru now.
DAR will backup your files into 'slices' that can be any size of your choosing. There is also a program called daromizer that will run those slices off onto CD's, DVD's. You could also run the slices off to tape. I was using daromizer for awhile but ran into too many errors on my RW DVD's so I now use DAR to back up to disk, and then a separate process to offload onto DVD's. That way, if I get an error, I haven't lost the slice like I would if using daromizer. I can retry to off-load. Dar will compress files to a level of your choosing (speed -size tradeoff) and also avoid compressing files that shouldn't be (you choose). Things like .bin, .jpg, etc. It's a nice program. I can backup 13G's of stuff in about 2.5 hours.
On Tue, 18 Jan 2005 15:20:48 -0500, you wrote: [snippage]
I was using daromizer for awhile but ran into too many errors on my RW DVD's so I now use DAR to back up to disk, and then a separate process to offload onto DVD's. That way, if I get an error, I haven't lost the slice like I would if using daromizer. I can retry to off-load.
What version of daromizer? Not only does version .8 support retrying a failed burn (or format on an RW device), but there's a verify option - which needs more work (MUCH too slow). And a minor correction. You don't need daromizer to burn slices to your preferred media - daromizer just allows the slice creation process and the burn process to run in parallel. Saves time, is all. Mike- (who wrote daromizer) -- If you can keep your head while those around you are losing theirs... You may have a great career as a network administrator ahead! -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments,
On Tue, 18 Jan 2005 13:21:51 -0600, you wrote:
I have used BRU, but it was a long time ago ...like a couple years, I think. That one came w/Caldera Open Linux. I do know that the version I used had no speed tweaks. I backed up to disk, burned to CDs. The 2+/- GB of data I backed up on that particular box took about 1.5 hours, I think. It is a lengthy process no matter what one uses, but lately I have taken to using DAR and like the fact that it'll back up quite rapidly the 5+GB I now have. I have never timed it but know it happens more quickly than you have indicated.
I take it DAR backs up to another hard disk in the system. Correct me if im wrong.
DAR backs up to DVDs, CDs, Floppies, ZIP drives. Basically anything where you need your backup 'sliced up' to fit on the media. DAR is as fast as your media layer, more or less. Mike- -- If you can keep your head while those around you are losing theirs... You may have a great career as a network administrator ahead! -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments,
On Tue, 18 Jan 2005 12:18:38 -0600, Jack Malone
I'm trying out the personal version of bru for backinging up some samab shares here. Just wondering who is using it out there an if you did any speed tweaks to increase the speed of backups. I did a test backup this morning of about 1 gig of data an it took 30 minutes to complete it. Based on that time frame the 11 gigs I have in the samba share would take up to 5 hours or so to finish. I did a test with the buffersize at 64k an 128k an it was same amount of time to do the backup in my testing. thanks for any help with this. I'm using a quantum DLT vS80 tape drive.
thanks
jack
That's pretty slow. It is bad for your DLT drive to run that slow, so you really do need to make the process faster. (i.e. The shoe-shining noises you are hearing are adding lots of wear and tear to the tape drive.) How long does it take if you backup your 1GB to /dev/null? How long does it take if you dd 1GB of /dev/zero to the tape (Be sure to adjust your block sizes)? Typically a slow backup is caused by traversing the filesystem, not the tape system. Assuming that it is bru (ie. the filesystem) that is slow, with only 11 GB you will be better off to do your BRU backup do a dedicated xfs filesystem on a dedicated drive. (ie. /dev/hdc1). Then just dd the backup file to tape. That way the tape / filesystem speed issues will not degrade each other. Overall, the $100 (or less) you spend to put in a backup staging disk will more than pay for itself by eliminating wear and tear on your DLT drive. FYI: This concept is also called a D2D2T (Disk to Disk to Tape) backup strategy, or a mezzanine backup strategy. The more sophisticated versions keep several recent backups on disk and restores from those recent backups come in directly from disk. Greg -- Greg Freemyer
At 01:25 PM 1/18/2005, Greg Freemyer wrote:
That's pretty slow. It is bad for your DLT drive to run that slow, so you really do need to make the process faster. (i.e. The shoe-shining noises you are hearing are adding lots of wear and tear to the tape drive.)
How long does it take if you backup your 1GB to /dev/null?
How long does it take if you dd 1GB of /dev/zero to the tape (Be sure to adjust your block sizes)?
Typically a slow backup is caused by traversing the filesystem, not the tape system.
Assuming that it is bru (ie. the filesystem) that is slow, with only 11 GB you will be better off to do your BRU backup do a dedicated xfs filesystem on a dedicated drive. (ie. /dev/hdc1).
Then just dd the backup file to tape. That way the tape / filesystem speed issues will not degrade each other.
Overall, the $100 (or less) you spend to put in a backup staging disk will more than pay for itself by eliminating wear and tear on your DLT drive.
FYI: This concept is also called a D2D2T (Disk to Disk to Tape) backup strategy, or a mezzanine backup strategy. The more sophisticated versions keep several recent backups on disk and restores from those recent backups come in directly from disk.
Hey Greg, thanks for replying back. I also did this same test with tar an it took the same amount of time. Now the 1 gig stuff I backed up was not the same stuff that would be backed up when I put the system into production. I am doing this on my test bench machine here my office before I put it in the actual server. I do have a spare hd in the server to help with the d2d2t setup already. I used to have a dat drive in a windows machine that backed up the server samba share at night an it would do this 11 gigs in 2 hours time, ( my bosses ideal to keep it in the workstation). Back in dec that dat tape drive went bad after 5 years of use. I also backup the samba share to my workstations to a hard drive for that purpurse only an keep a few weeks of backups that way right now. I convince boss to put the new tape drive in linux server if i can get it working right. Ok so you say to dd the backup file to tape, I'm assuming your meaning to us dd to archive/ copy the backup file to the tape drive. After I hear back from you I will give this a try. never used the dd command but have seen serval messages referencing it in other ways. thanks jack
On Tue, 18 Jan 2005 13:41:29 -0600, Jack Malone wrote:
At 01:25 PM 1/18/2005, Greg Freemyer wrote:
That's pretty slow. It is bad for your DLT drive to run that slow, so you really do need to make the process faster. (i.e. The shoe-shining noises you are hearing are adding lots of wear and tear to the tape drive.)
How long does it take if you backup your 1GB to /dev/null?
How long does it take if you dd 1GB of /dev/zero to the tape (Be sure to adjust your block sizes)?
Typically a slow backup is caused by traversing the filesystem, not the tape system.
Assuming that it is bru (ie. the filesystem) that is slow, with only 11 GB you will be better off to do your BRU backup do a dedicated xfs filesystem on a dedicated drive. (ie. /dev/hdc1).
Then just dd the backup file to tape. That way the tape / filesystem speed issues will not degrade each other.
Overall, the $100 (or less) you spend to put in a backup staging disk will more than pay for itself by eliminating wear and tear on your DLT drive.
FYI: This concept is also called a D2D2T (Disk to Disk to Tape) backup strategy, or a mezzanine backup strategy. The more sophisticated versions keep several recent backups on disk and restores from those recent backups come in directly from disk.
Hey Greg, thanks for replying back. I also did this same test with tar an it took the same amount of time. Now the 1 gig stuff I backed up was not the same stuff that would be backed up when I put the system into production. I am doing this on my test bench machine here my office before I put it in the actual server. I do have a spare hd in the server to help with the d2d2t setup already. I used to have a dat drive in a windows machine that backed up the server samba share at night an it would do this 11 gigs in 2 hours time, ( my bosses ideal to keep it in the workstation). Back in dec that dat tape drive went bad after 5 years of use. I also backup the samba share to my workstations to a hard drive for that purpurse only an keep a few weeks of backups that way right now. I convince boss to put the new tape drive in linux server if i can get it working right.
Ok so you say to dd the backup file to tape, I'm assuming your meaning to us dd to archive/ copy the backup file to the tape drive. After I hear back from you I will give this a try. never used the dd command but have seen serval messages referencing it in other ways.
thanks jack
dd is one of the truly basic linux/unix commands. Basically anybody doing sysadm should get familiar with it. Unfortunately it has a rather unique syntax. Anyway, assume your backup is at /mnt/backup.bru To put that to tape: dd if=/mnt/backup.bru of=/dev/st0 bs=64k if --- input file of -- output file bs -- blocksize (Pick one you like, but be consistent. I always write it on the tape label). Two other args I use a lot are 'count=xxx' and 'conv=noerror,sync'. You should be able to use bru to directly restore a tape made like above, as long as you give dd and bru the same block sizes. If for some reason bru won't restore from tapes made this way you can use dd to restore to disk, then bru to restore from the disk file. Greg -- Greg Freemyer
How long does it take if you dd 1GB of /dev/zero to the tape (Be sure to adjust your block sizes)?
doing dd if=/dev/zero of=dev/st0 bs=128k i get a segmentation fault, so I can not answer that at this time.
Overall, the $100 (or less) you spend to put in a backup staging disk will more than pay for itself by eliminating wear and tear on your DLT drive.
FYI: This concept is also called a D2D2T (Disk to Disk to Tape) backup strategy, or a mezzanine backup strategy. The more sophisticated versions keep several recent backups on disk and restores from those recent backups come in directly from disk.
dd is one of the truly basic linux/unix commands. Basically anybody doing sysadm should get familiar with it. Unfortunately it has a rather unique syntax.
Thanks greg for the info. Would you suggest any other software to use for the d2d backup part of the scheme then bru. I have not bought bru just checking out the demo version is all right now. I have a cd coming in the mail ca, there rep has been calling left an right since I downloaded a windows version hehehehe. I'm not stuck on bru just trying it out since it had a demo to try. I just need a good reliable backup scheme to use. I already have a spare 120 gig ide drive to use in the main system, an will drop i a spare in the testbench machine for testing tomorrow. I do like the ideal of the d2d2t scheme. Just hard to convince my boss of new ways of doing things at times. he is old an close to retiring. again thanks for your info an help. I have played with a 1 gig tar file an dd with setting bs=64, then bs=128k an still took 30 minutes to put it on the tape. It might be the old 3ware raid card I have in the system that is causing the slowdown, I using raid level 0 on this test machine. well back to some more reading an testing jack
On Wed, 19 Jan 2005 14:31:41 -0600, Jack Malone
How long does it take if you dd 1GB of /dev/zero to the tape (Be sure to adjust your block sizes)?
doing dd if=/dev/zero of=dev/st0 bs=128k i get a segmentation fault, so I can not answer that at this time.
Overall, the $100 (or less) you spend to put in a backup staging disk will more than pay for itself by eliminating wear and tear on your DLT drive.
FYI: This concept is also called a D2D2T (Disk to Disk to Tape) backup strategy, or a mezzanine backup strategy. The more sophisticated versions keep several recent backups on disk and restores from those recent backups come in directly from disk.
dd is one of the truly basic linux/unix commands. Basically anybody doing sysadm should get familiar with it. Unfortunately it has a rather unique syntax.
Thanks greg for the info. Would you suggest any other software to use for the d2d backup part of the scheme then bru. I have not bought bru just checking out the demo version is all right now. I have a cd coming in the mail ca, there rep has been calling left an right since I downloaded a windows version hehehehe. I'm not stuck on bru just trying it out since it had a demo to try.
I don't know what bru cost, but we use Data Protector from HP for our backups. It is neither cheap, nor outrageously expensive (~$1,000 to to get started, but adding networked computers to the backups set is free.) Unfortunately it requires at least one Windows box to admin the backup process.
I just need a good reliable backup scheme to use. I already have a spare 120 gig ide drive to use in the main system, an will drop i a spare in the testbench machine for testing tomorrow. I do like the ideal of the d2d2t scheme. Just hard to convince my boss of new ways of doing things at times. he is old an close to retiring. again thanks for your info an help.
All the commercial backup providers are moving to d2d2t methodologies. The middle 'd' is one of the core targets for some of HP and EMC's latest offerings. ie. Large arrays of SATA drives. Often, many TBs. IBM's Tivoli Storage Manager has supported d2d2t for several years. So you need to explain you are going upscale!!!
I have played with a 1 gig tar file an dd with setting bs=64, then bs=128k an still took 30 minutes to put it on the tape. It might be the old 3ware raid card I have in the system that is causing the slowdown, I using raid level 0 on this test machine.
well back to some more reading an testing
Try testing a raw disk to tape copy. dd if=/dev/hdc1 of=/dev/st0 bs=128k count=8000 (1GB = 128k * 8000 right?) If that is faster, then it is your filesystem that is not keeping up. If so, XFS is very good (fast) at handling large files and I recommend it for the staging disk.
jack
Greg -- Greg Freemyer
On Tuesday 18 January 2005 09:18 am, Jack Malone wrote:
I'm trying out the personal version of bru for backinging up some samab shares here. Just wondering who is using it out there an if you did any speed tweaks to increase the speed of backups. I did a test backup this morning of about 1 gig of data an it took 30 minutes to complete it. Based on that time frame the 11 gigs I have in the samba share would take up to 5 hours or so to finish. I did a test with the buffersize at 64k an 128k an it was same amount of time to do the backup in my testing. thanks for any help with this. I'm using a quantum DLT vS80 tape drive.
thanks
jack
Ours seems to consistantly get in excess of 3558 Kb per second according to the bruexec log: wrote 4144128 blocks (8,288,256 KBytes) on volume [1], 0:31:00, 4456 Kb/sec wrote 26695008 blocks (53,390,016 KBytes) on volume [1], 4:10:04, 3558 Kb/sec wrote 1274208 blocks (2,548,416 KBytes) on volume [1], 0:11:32, 3682 Kb/sec Its getting about 16gig per minute. This is from drives in the same machine. All the data just moving from the hard drive array to the tape. (All devices SCSI). You say you were backing up samba shares, did you mean in the same machine, or from another machine (across the network)? ------------------------------------------------------------ Here is what I use a the brutab for our DLT cat brutab # # These look funny, but global parameters are defined with # "#+" (pound-plus) syntax. If you wish to comment them out, # insert anonther #. E.g. "# #+..." # #+MOUNTCMD=/bin/mountcmd.sh # #+UNMOUNTCMD=/bin/unmountcmd.sh #+OVERWRITEPROTECT=yes #+RECYCLEDAYS=7 # The first device listed will be the default device. /dev/st0 devname="PowerVault DLT Drive" \ size=0 bufsize=64k \ tape rewind autoscan /dev/nst0 devname="PowerVault DLT Drive" \ size=0 bufsize=64k \ tape norewind noautoscan \ fmtcmd="mt -f /dev/nst0 erase" \ rfmcmd="mt -f /dev/nst0 fsf" \ retencmd="mt -f /dev/nst0 reten" \ rewindcmd="mt -f /dev/nst0 rewind" \ eodcmd="mt -f /dev/nst0 eod" # Bit bucket for testing /dev/null bufsize=20k norewind noautoscan # Entry for stdin/stdout -- DO NOT PUT FIRST - bufsize=20k norewind noautoscan -- _____________________________________ John Andersen
participants (9)
-
Bruce Marshall -
C Hamel -
Greg Freemyer -
Jack Malone -
Joe Morris (NTM) -
John Andersen -
Jon Nelson -
Michael W Cocke -
riccardo