January 2009 - openSUSE Users - openSUSE Mailing Lists

[opensuse] SuSE 11.1 Cell Phone Tethering
by Michael A. Sterba 01 Jan '09

01 Jan '09

Hello Listmates, I have run into a problem with tethering my cellphone as a external modem since my upgrade. Under knetwork manager in either KDE 3.5 or KDE 4.1 I don't have the selection to start-up and/or configure a dialup connection. It appears this option has been removed. How do I add it back in? The tethering is my fall back connection when out in the field away from normal wifi/ethernet connections under emergent situations. I'm not worried about speed issues, just the availability for usage. What I do get is on a USB connection it registers as /dev/ttyACM0 in knetwork manager. But when I go to configure and connect, I don't get the handshaking. I have verified my baud rates so that shouldn't be an issue. I can use minicom and get the port to reply so I know the hardware and cabling are fine making this a software and/or configuration issue. I have tried configuring it as a modem under yast. It initially shows up as the cellphone type. But when trying to edit the configuration, it shows it as a separate modem (modem0) which still doesn't show under knetwork manager. This is the first time since SuSE 9.0 that I have run into this issue and it's stumping me. -- Thank you, Michael.A.Sterba -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

2 3

[opensuse] RAID disarray
by Bob Williams 01 Jan '09

01 Jan '09

In my old machine I had a two disk RAID1 array mounted on /home. I have transferred these two disks to a new machine, on which I have installed openSUSE 11.0. The operating system partitions are all on a separate (third) drive. During the installation process, while in the Partitioner, Yast detected my /dev/md0 so I happily mounted it on /home, and everything seemed to proceed nicely. That was a few days ago, and since then quite a lot of data has been written to /home I have now discovered that /dev/md0 only consists of a single drive, /dev/sdc1, and /dev/sdb1 has been sitting idle, twiddling it's thumbs! I'd be grateful if someone could guide me through the process of reassembling the array, without losing/overwriting the new data on /dev/sdc1. I have read through man mdadm, but I'm not confident about my understanding. Or perhaps I could do it in Yast? Many thanks, and Happy New Year to you all :) Bob -- Registered Linux User #463880 FSFE Member #1300 GPG-FP: A6C1 457C 6DBA B13E 5524 F703 D12A FB79 926B 994E openSUSE 11.0, Kernel 2.6.25.18-0.2-default, KDE 3.5.10 Intel Celeron 2.53GHz, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

3 7

[opensuse] Help -script guru's
by Philip Burness 01 Jan '09

01 Jan '09

Could anybody provide me with a script that removes or replaces non compatible characters from file / directory names so that such files can be stored on a vfat filesystem? Thanks Phil -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

3 3

[opensuse] SSD storage and new Linux kernels [was: Re: IFUP (WAS: Re:knetworkmanager in 11)]
by Greg Freemyer 01 Jan '09

01 Jan '09

On Sat, Dec 27, 2008 at 8:23 PM, Randall R Schulz <rschulz(a)sonic.net> wrote: > On Saturday 27 December 2008 16:03, James Knott wrote: >> ... >> >> With that, you raise the question of how often you write vs read. > > Well, it is a pattern observed in all information processing that reads > outnumber writes at all levels (CPU registers, level-1 and level-2 > cache, RAM and secondary storage), but that does not change the fact > that flash-based secondary storage cannot sustain as many write cycles > as rotating magnetic media. To date, fancy redundancy schemes are > required to balance the read / write cycle limits in flash-RAM devices > when used as secondary storage devices. Finally read this thread. The subject was left far behind. First, the earlier parts of the discussion seemed to assume most hard drive failures are caused by head crashes. We do disk recovery as part of our services. Our experience is that most failures are in the electronics of the drive, not the mechanical part. If you read the Google whitepaper on disk drive reliability, they conclude that disk drives fail independent of disk usage, so I really think the conceptual idea of having a limited number of disks writes is a very minor issue compared with drives failing just because electronics routinely fail after a period of time. As to the SSD discussion: I find it really interesting and I do suspect it is where we are headed. The linux kernel now has SSD support built into some of the filesystems. (ext3?, others?) The way it works is really cool to me. First the hardware side: When a SSD is new, the onboard electronics knows that none of the sectors are in use. When a sector is written to, the onboard electronics note the fact by removing them from the "free" list. Not only is that tracked but the number of times a sector has been written is also tracked. So when you go to update a commonly used sector (ie. the filesystem superblock) the wear-leveling algorithm says, I'm going to remap that sector to a lesser used sector, lets see what I have in the free list that has the least number of writes. Thus when you write to a sector, you are always providing just a logical sector id and have no idea which physical sectors are really being written. That all happens in hardware and I don't think requires any kernel support, but as you think about it, you start to wonder how sectors that are freed at the filesystem level get freed at the SSD hardware level for reuse. In particular I had considered that case of doing a disk wipe. Once you do that, the SSD should see all the sectors as used, so the wear-leveling algorithm should quit working from that point forward. And that is where the kernel side kicks in: That answer is that the ATA spec has been extended to support a "discard" command. And the linux kernel is adding support in various filesystems to invoke discard on any sectors that become free due to file deletion, etc. The end result is that those limited write cycles get to be spread across all of the "free" SSD sectors. That also means you will not want to use a SSD in such a way that it stays mostly full, but that a small part of the data is constantly changing. Aiui, that would cause the SSD to churn through the small number of free sectors very quickly and use up their limited write-cycles. I don't know if strategies to address this are in place yet. And I don't think the actual wear-leveling algorithms are public knowledge, so it is just guess work how this all works in detail. FYI: For those saying, what is OpenSUSE 10.3 lacking that would cause me to upgrade. If you want to use SSD storage, I suspect you will need a newer kernel than 10.3 offers. In reality you will need to research when SSD discard support was added to your filesystem of choice and then be sure you have a kernel new enough to have it. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

5 9

[opensuse] Linux VTL
by Ciro Iriarte 01 Jan '09

01 Jan '09

Hi, anyone tried this linux VTL implementation (http://markh794.googlepages.com/)?, apparently it's not included in the openSUSE kernel. Would be nice to have an opensource VTL solution with deduplication :D Regards, -- Ciro Iriarte http://cyruspy.wordpress.com -- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

1 0