- WLUG - wlug.mailman3.com

Re: [Wlug] the website is in need of some love

by Chuck Anderson

On Thu, Apr 01, 2010 at 09:20:44AM -0400, Jeff Moyer wrote: > I'm not sure who maintains it, but it's in a very sad state at the > moment. Congratulations! You've just been volunteered to enhance it! :-) But hey, at least it validates now. Seriously though, if anyone would like to help, feel free to email me. There was a time when I was playing with Moin for a wiki site but that fell by the wayside. I really need to rebuild the system that the web server is running on, so I could deploy something new/better if there was someone who would commit to helping maintain it. I just don't have the time to do anything fancy, learn new web frameworks, etc. Alternatively, people could submit some designs, code, and content that uses plain HTML/CSS and I could maintain that manually.

April 1, 2010

How to manipulate audio (ALSA) a lot with a HD audio card?

by Tatsh

Stupid Intel decided to build-in DRM into the spec of these things. I have a Conexant which has Nvidia codec to provide audio for the HDMI output (this works fine except that in alsa settings I have to force a default output device, 3). What I'd like to do is be able to record from the stereo mixer, which I have none in alsamixer. So how do I go about creating one? I've tried a few different configs I found on-line but nothing seemed to work for me. WIth this capability of course I could record audio from my computer in say, Audacity, or I could even broadcast audio through Skype. And the best part would be if I could broadcast audio through Skype AND use my headset at the same time (mixing the 2 into one channel input). I have 3 mic inputs apparently (one of them is webcam, another is the jack, and I don't know what the 3rd one is). Image of KMix: http://bitpic.net/image/kmix-nvidia-hd-audio-codec So far I know it's something I can do with ALSA settings where I can tell ALSA to redirect audio and 'copy' whatever is going on on any input channel (overriding the jack of course). No luck there yet. Any help appreciated Thanks -- Tatsh www.bitpic.net www.tatsh.net ddrtist(a)gmail.com

April 1, 2010

Re: [Wlug] the website is in need of some love

by Tatsh

Would be cool to do it over in Drupal. NOT JOOMLA (should be called 'piece of crap please give up already!')! All you need is a blog post system (built-in) to write about events, and add custom fields like time if you want, etc etc. From a design stand point, there is no reason to use images for the textual links, especially obviously compressed JPEGs. Late Jeff Moyer wrote: > I'm not sure who maintains it, but it's in a very sad state at the > moment. > > Cheers, > Jeff > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > -- Tatsh www.tatsh.net ddrtist(a)gmail.com

April 1, 2010

the website is in need of some love

by Jeff Moyer

I'm not sure who maintains it, but it's in a very sad state at the moment. Cheers, Jeff

April 1, 2010

Re: [Wlug] interesting article on RAID

by John Stoffel

Theo> Yeah, it's complicated by the fact that a lot of RAID systems Theo> will consider any I/O error to mean the entire device is bad. This is why Netapp has moved to their double-parity raid sets. It's a help, but not perfect. I'm going to read the article in a few and then comment in particular. Theo> ZFS does a particularly good job here, I've seen single raidz2 Theo> sets able to recover from having 4 simultaneously failing disks. Now that's interesting. How was performance during this issue? Theo> I've had other vendor's arrays start failing disks while Theo> reconstructing from a single failure. Thankfully it was only 1 Theo> additional failure on a 2 parity set. Still PITA. I once had a double disk failure in a Netapp. Ouch! This was before their double parity stuff was widely deployed. One disk died due to head problems, the other died due to the controller board on the disk dying. I managed to swap the good board from the bad hardware disk onto the good hardware, bad board disk, re-insert it and have the system come back up and rebuild. Big sigh of relief there for sure! Another thing I like about alot of newer raid implementations (including Linux RAID, assuming you use it) is the consistency checks or scrubbing that you can run, to hopefully catch errors before they become problems. Reading the disk(s) and checking blocks for consistency, and even re-writing them to make sure the data is good. John

March 12, 2010

Re: [Wlug] interesting article on RAID

by Theo Van Dinter

Yeah, it's complicated by the fact that a lot of RAID systems will consider any I/O error to mean the entire device is bad. ZFS does a particularly good job here, I've seen single raidz2 sets able to recover from having 4 simultaneously failing disks. I've had other vendor's arrays start failing disks while reconstructing from a single failure. Thankfully it was only 1 additional failure on a 2 parity set. Still PITA. On Thu, Mar 11, 2010 at 8:09 PM, Chuck Anderson <cra(a)wpi.edu> wrote: > Triple-Parity RAID and Beyond > by Adam Leventhal | December 17, 2009 > > http://queue.acm.org/detail.cfm?id=1670144 > > As hard-drive capacities continue to outpace their throughput, the > time has come for a new level of RAID.

March 12, 2010

interesting article on RAID

by Chuck Anderson

Triple-Parity RAID and Beyond by Adam Leventhal | December 17, 2009 http://queue.acm.org/detail.cfm?id=1670144 As hard-drive capacities continue to outpace their throughput, the time has come for a new level of RAID. -- - Chuck (372 Days until IPv4 depletion: http://ipv4depletion.com/)

March 12, 2010

Meeting: BtrFS: Now (Thurs March 11 7pm)

by Chuck Anderson

Frank is giving a talk on BtrFS right now. It seems the website wasn't updated (but is now). -- - Chuck (372 Days until IPv4 depletion: http://ipv4depletion.com/) On Mon, Feb 22, 2010 at 06:18:44AM -0500, Frank Sweetser wrote: > I've noticed that not too many people have putting in meeting topic requests, > so I thought that if anyone's interested I'd volunteer to throw together some > slides on BtrFS. > > For those of you who haven't heard of it, BtrFS is the next generation linux > filesystem. Though still in heavy development, it was included in the > mainstream kernel last year. It promises to scale to filesystems well beyond > what any of the current offerings can handle (including ext4), as well as > offering far greater flexibility and better data security for data admins. > > If you have anything else that you'd like to hear about, either instead of or > in addition to BtrFS, chime in, and hopefully someone else on the list will be > able to make it happen! > > -- > Frank Sweetser fs at wpi.edu | For every problem, there is a solution that > WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken > GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC

March 12, 2010

Re: [Wlug] Meeting topics

by Jeff Moyer

"John Stoffel" <john(a)stoffel.org> writes: >>>>>> "Jeff" == Jeff Moyer <jmoyer(a)redhat.com> writes: > Jeff> I've seen many claims that SSDs are more reliable than > Jeff> traditional HDDs, but I haven't seen data to back up those > Jeff> claims. > > Some of the arguements I've read on SSD reliability are quite > interesting. If you do the math on how much data you need to write to > destroy an SSD with proper (note!) wear levelling, it's really quite > high. But I think the real key is to write data to them in blocks of > 512 bytes as much as possible, and to not write smaller amounts if at > all possible. Did you mean to say 512KB? You can't write smaller than the exported block size (which will be either 512 bytes or 4k). Perhaps what you meant to say was that you should try to issue writes that are aligned on and multiples of the erase block size. > Jeff> My main concern is that SSDs are still young, so they haven't > Jeff> had much soak time. Whether or not the flash is reliable is > Jeff> only a small part of the battle. Buggy firmware is a much more > Jeff> likely problem at this stage in the game. No single point of > Jeff> failure is a good design point when dealing with your data. ;-) > > I think this is a key issue, the firmware and controllers, not the > flash chips themselves. > > Jeff> I remain cautiously optimistic (though I've already bricked one > Jeff> drive). > > Details? During TRIM testing, we managed to get an OCZ Vertex to spew I/O errors, and then finally fail to be recognized by the BIOS upon reboot. Note that this isn't a normal workload (the drive is being pounded on) and TRIM is still very new. So, I am not saying that the drives are not reliable in general. I simply don't know. Cheers, Jeff

March 2, 2010

Re: [Wlug] Meeting topics

by John Stoffel

>>>>> "Jeff" == Jeff Moyer <jmoyer(a)redhat.com> writes: Jeff> Chuck Anderson <cra(a)WPI.EDU> writes: >> On Mon, Mar 01, 2010 at 04:46:44PM -0500, Jim Dibb wrote: >>> On Mon, Mar 1, 2010 at 4:21 PM, Chuck Anderson <cra(a)wpi.edu> wrote: >>>> I'm interested. I was considering using SSDs for my boot drive. Is >>>> RAID protection necessary/advisable using SSDs? >>> >>> SSDs have much higher reliability than HDD. >>> Mirroring is the only RAID level that does not impose a write penalty. >>> Mirroring SSDs is expensive >>> >>> Based on these 3 points, I'd say a backup is a much better solution than >>> RAID, unless you want to (R)AID-0 them into a stripe for even more insane >>> performance. >>> >>> But then again, you didn't state how important your uptime of your system >>> is. Sorry for leaving that bit out.... >> >> Uptime/availability isn't that important, but backups are since RAID >> *is* my backup (plus rsync to other RAIDed systems for the most >> important data). With traditional disk drives, it hasn't been too >> expensive to slap a 2nd system drive in for RAID 1/mirroring. SSDs >> are much more expensive, so if as you say they are more reliable, >> perhaps I can forgo the expense of doing RAID on them. Jeff> I've seen many claims that SSDs are more reliable than Jeff> traditional HDDs, but I haven't seen data to back up those Jeff> claims. Some of the arguements I've read on SSD reliability are quite interesting. If you do the math on how much data you need to write to destroy an SSD with proper (note!) wear levelling, it's really quite high. But I think the real key is to write data to them in blocks of 512 bytes as much as possible, and to not write smaller amounts if at all possible. Jeff> My main concern is that SSDs are still young, so they haven't Jeff> had much soak time. Whether or not the flash is reliable is Jeff> only a small part of the battle. Buggy firmware is a much more Jeff> likely problem at this stage in the game. No single point of Jeff> failure is a good design point when dealing with your data. ;-) I think this is a key issue, the firmware and controllers, not the flash chips themselves. Jeff> I remain cautiously optimistic (though I've already bricked one Jeff> drive). Details? John

March 2, 2010