[kwlug-disc] kwlug-disc_kwlug.org Digest, Vol 23, Issue 42
David Christensen
davidchristensen42 at gmail.com
Mon Oct 25 12:25:05 EDT 2010
On Mon, Oct 25, 2010 at 12:00 PM, <kwlug-disc-request at kwlug.org> wrote:
> Send kwlug-disc_kwlug.org mailing list submissions to
> kwlug-disc at kwlug.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
> or, via email, send a message with subject or body 'help' to
> kwlug-disc-request at kwlug.org
>
> You can reach the person managing the list at
> kwlug-disc-owner at kwlug.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kwlug-disc_kwlug.org digest..."
>
>
> Today's Topics:
>
> 1. Re: Media errors on a USB disk (Eric Gerlach)
> 2. Re: Fast transfer protocol? (unsolicited)
> 3. Re: Fast transfer protocol? (John Johnson)
> 4. screen is keen (Richard Weait)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 24 Oct 2010 13:06:37 -0400
> From: Eric Gerlach <eric+kwlug at gerlach.ca <eric%2Bkwlug at gerlach.ca>>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Subject: Re: [kwlug-disc] Media errors on a USB disk
> Message-ID:
> <AANLkTinUBGGz1sJmsfkdaAsgwUvnL6HvgkB50=ZXgNpt at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Oct 24, 2010 at 10:25 AM, Bob Jonkman <bjonkman at sobac.com> wrote:
> > This is why I wonder about Spinrite. ?While it seems to be an awesome
> > program, it DOES pay attention to partition tables and partitions, so
> it's
> > not just checking the raw sectors on the disk. But it checks an ext3
> > partition just as readily as an NTFS partition.
>
> I don't know why it allows that option either... I've only ever run it
> on entire disks, and don't know why you would want otherwise. It
> definitely operates on the block level, though.
>
> > FWIW, I've never managed to recover a damaged drive with Spinrite.
> ?Either
> > the drives I checked aren't badly enough damaged, so Spinrite indicates
> > they're good, or the drive is so badly damaged that even Spinrite can't
> read
> > it. ?I've had a drive that banged its heads against the backstop, run
> > Spinrite on it for 30 days continuously, and while Spinrite marked most
> of
> > the drive as "Bad" it didn't recover a thing.
>
> What's interesting is that because of the way SpinRite does things at
> Level 4 (read, invert, write, read, invert, write, read), it will
> sometimes cause the drive to catch sectors that are bad, but the drive
> didn't realise it. In the story I submitted to Security Now (which
> got read on the air twice), when SpinRite ran it didn't do any
> "DynaStat" recovery. But the drive worked afterwards. So you don't
> always *see* it working. Sometimes it just helps the drive out, and
> since the drive doesn't say "Thank You," it can't tell you it did
> anything.
>
> I will agree though, that many of the times a user comes to me and
> says "I think my HD is bad," the drive is too far gone for anything.
>
> Cheers,
>
> Eric
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 24 Oct 2010 14:35:58 -0400
> From: unsolicited <unsolicited at swiz.ca>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Subject: Re: [kwlug-disc] Fast transfer protocol?
> Message-ID: <4CC47C8E.6020608 at swiz.ca>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Paul Nijjar wrote, On 10/24/2010 12:41 AM:
>
> > So I ended up testing with a program called iperf
> > (http://iperf.sourceforge.net) which appears to be a pretty standard
> > network testing tool. Because I am lazy I used precompiled versions,
> > which meant that there were version issues between the Windows version
> > (1.70) and the version on my Knoppix LiveCD (2.0.3 or something).
>
> Looks like 2.0.4-1 is in the cygwin repository.
>
> > I can pretty much max out my gigabit connection using iperf and two
> > Windows servers with built-in gigabit cards. Any other combination of
> > Windows/Linux maxes out at about 60% usage.
> >
> > Samba is indeed slow. I get better throughput with an FTP server. Disk
> > does indeed appear to be a limiting factor.
>
> Any chance you accumulated numbers for standard windows file sharing?
> Differences would be interesting - would mean there's some
> efficiencies gained within the windows code. No differences would be
> reassuring, and indicate that 'file sharing' is whatever (speed) it is.
>
> > On at least one machine (one with Windows and Linux) I found that
> > something in the operating system and/or version of iperf makes the
> > results pretty different.
>
> Can anyone comment ... how much of this difference might be
> attributable to proprietary windows (netcard?) drivers?
>
> - I'm guessing there are no proprietary linux drivers available to be
> played with in Paul's test. (Unlike, say, proprietary nvidia drivers.)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 24 Oct 2010 14:50:39 -0400
> From: John Johnson <jvj at golden.net>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Subject: Re: [kwlug-disc] Fast transfer protocol?
> Message-ID: <201010241850.o9OIoatu027381 at smtp2.execulink.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 00:41 2010-10-24, you wrote:
> >I can pretty much max out my gigabit connection using iperf and two
> >Windows servers with built-in gigabit cards. Any other combination of
> >Windows/Linux maxes out at about 60% usage.
>
> Congrats. IMHO This was no easy feat.
>
> In my earlier post I did say that I doubted that with "a PC" meaning
> a single PC (inferring but not stating at least a receiver /
> transmitter pair) one would be hard pressed to get sustained data
> transfers anywhere near 1 Gigabit/sec. I thought that multiple PCs
> would be needed to get the aggregate data rate up to those limits.
> And a software-only utility involves the fewest internal components,
> i.e. CPU, RAM, busses and bridges, and of course the network "cards".
>
> John Johnson
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 25 Oct 2010 07:40:20 -0400
> From: Richard Weait <richard at weait.com>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Subject: [kwlug-disc] screen is keen
> Message-ID:
> <AANLkTin2Gy50UsWFzrJdASt1OJS50VPkW227QA406bDp at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> You might remember a presentation on the GNU utility, screen, from a
> few meeting back. You might have thought, "sure that seems nice and
> all, but how do I add an animated wallpaper to it?"
>
> Or you might have thought, "hunh? Paul says it gets confused by sudo.
> I should probably remember that so it doesn't cause me trouble in the
> future."
>
> Let this be a lesson to you. Screen does get confused by sudo, so ssh
> in as the user who should be using screen. Thanks Paul for that tip
> that, had I remembered earlier, would have saved me ten minutes.
> Without your tip, I could have wasted hours.
>
> So screen is keen. I found it super-useful last week during a
> conference call regarding some server stuff. A developer and I used
> the same screen to work on the project via the -x option. We each
> ssh'd in to the server as the same user. I started a screen session.
> He used screen -x to attach to the existing screen session. Then we
> could each see what the other was typing, and all the results from
> those commands. This was a very handy way for two people with
> different skill sets to collaborate on a project. When combined with
> a telephone call for a simultaneous voice connection, it felt very
> productive.
>
> Plus the whacky, "I'm going to press enter when you are typing your
> password" hijinx.
>
> So, it was good fun. Screen is Keen. Paul's presentation saved me some
> time.
>
> Apparently screen will let different users attach to the same session,
> but I haven't tried that yet.
>
Test
>
>
>
> ------------------------------
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>
>
> End of kwlug-disc_kwlug.org Digest, Vol 23, Issue 42
> ****************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20101025/b0a5c22d/attachment.htm>
More information about the kwlug-disc
mailing list