- luv-main - luv.asn.au

iscsi (was RE: drdb and mdadm and more)
by James Harper 10 Apr '12

10 Apr '12

> > The random i/o interspersed with the rebuild i/o has the effect of totally > trashing the rebuild performance. Random i/o over iscsi has sucked on the > stable Debian kernels. (I believe the better-performing iscsi drivers (which > are a totally independent rewrite) have finally made it into wheezy though.) > Are you referring to the target, initiator, or both here? Wheezy has lio target now which is marketed as faster and better than everything else, although there are arguments about that from the other iscsi target camps... I think lio also has an initiator but I haven't seen Debian packages for that yet. I'm using lio after using iscsitarget (iet) without any problems. James

2 1

Mapping - New development
by Andrew Greig 10 Apr '12

10 Apr '12

Hi, I am trying to make some sense of this news, http://www.zdnet.com/blog/btl/microsofts-purchase-of-aol-patents-may-be-abo… is Open Street Map securely placed as an Open Source project, or not? Andrew

1 0

USB3 kernel support
by James Harper 09 Apr '12

09 Apr '12

In the interests of getting around 1TB of data onto disk faster for offsite backups, we bought a PCIe USB3 adapter: lspci 16:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev ff) pspci -n 16:00.0 0c03: 1033:0194 (rev ff) and also a USB3 caddy that holds bare disks. This was working great on a test machine so we moved it across to a production machine and it's being nothing but trouble. The test machine is a HP ML110G6, and the production machine is a HP ML370G5. The adapter uses the xhci_hcd module, and after it plays up and I try and unload and load the module it says: [353709.836103] xen: registering gsi 19 triggering 0 polarity 1 [353709.836113] xen_map_pirq_gsi: returning irq 19 for gsi 19 [353709.836117] xen: --> pirq=19 -> irq=19 (gsi=19) [353709.836121] Already setup the GSI :19 [353709.836125] xhci_hcd 0000:16:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [353709.836204] xhci_hcd 0000:16:00.0: xHCI Host Controller [353709.836225] xhci_hcd 0000:16:00.0: new USB bus registered, assigned bus number 1 [353709.836253] xhci_hcd 0000:16:00.0: can't setup [353709.836349] xhci_hcd 0000:16:00.0: USB bus 1 deregistered [353709.836419] xhci_hcd 0000:16:00.0: PCI INT A disabled [353709.836423] xhci_hcd 0000:16:00.0: init 0000:16:00.0 fail, -19 So something has gotten stuck somewhere. I'm running debian 3.2.0-2-amd64 kernel. It seems that the USB3 caddy is no longer working as it also exhibits similar symptoms when plugged in to a USB2 port, but I've tried other USB2 and USB3 devices on the USB3 adapter and they appear to be doing similar things so now I'm not so sure. Any suggestions? Can anyone name an adapter that is working well for them? Thanks James

2 1

linux label printer?
by Craig Sanders 08 Apr '12

08 Apr '12

can anyone recommend a decent reasonably-priced small label printer that works well with linux and standard text-processing tools. powered from the USB interface would be nice but not essential. multiple suppliers of consumables would also be nice but, i guess, unlikey. i want to print some labels to put on stuff. like disk identifiers to stick on the handles of my hot-swap bays. nothing fancy, just needs to do a simple job, do it well, and not cost too much per label. if anyone has any tricks for controlling them from the command line (rather than openoffice or some gui label-printing app), i'd love to hear about it. e.g. in the first instance, I want to print sticky lables based on the output of: $ /bin/ls /dev/disk/by-id/| sed -rne '/ata-(ST|WDC)/s/ata-.*_//p' | grep -v -- -part 6VP3FWAG 9VP16X03 9VP18CCV 9VP4P4LN 9VP4RPXK 9VP509T5 WD-WCASJ2114122 WD-WCASJ2195141 WD-WMAV50817803 WD-WMAV50933036 i also want to be able to print once-off labels with something as simple as 'echo text | lpr -Plabelprinter' craig -- craig sanders <cas(a)taz.net.au> BOFH excuse #256: You need to install an RTFM interface.

5 8

Hardware to give way
by Sebastian 08 Apr '12

08 Apr '12

Hi, I have some hardware to give away. 1. ASUS A7V8X-X mainboard with a AMD Athlon processor. 256 MB RAM. Zalman fan on the CPU. Gigabyte GeForce2 MX 400 video card (dual display support). Sound Blaster sound card. DVD drive. Floppy drive. No power supply. All in a black Antec case. I haven't power this up for a while and don't have a ready way to test it; however, I believe it to be in working order. 2. Pentium 4 Socket 478 with Pentium 4 processor. 256 MB RAM. 3. Belkin Wireless G Desktop Network Card Hardware can be picked up from Northcote or maybe the city. E-mail me if you're interested in any or all of the above. Cheers, Sebastian

1 0

luv lists
by Lindsay Sprinter 07 Apr '12

07 Apr '12

Sorry to be a pain in the neck right to the end but my internet access system died over night and I am unable to remove myself from all of the lists including luv-announce would some one with the required access please do that for me as its is likely to be week before I can build a new box. The old ones only 14 years old with a 4 year old version of Debian on it so it is likely it has died of old age. lindsay

1 0

experience with XFS
by Anthony Shipman 07 Apr '12

07 Apr '12

I've been running a Centos 6.2 system for two months now. I've been using XFS for the /home file system since I had the impression it would be better for large file systems by avoiding long fsck times. At the same time the nvidia driver has proved to be buggy and has crashed the system several times. XFS has the habit of zeroing out some files each time there is a crash. This would be understandable for files that were being written around the time of the crash. But I've had files be erased that were created hours before the crash and were read-only after creation. I've set some sysctl parameters down to 5 seconds to flush more frequenctly fs.xfs.xfssyncd_centisecs = 500 fs.xfs.xfsbufd_centisecs = 100 fs.xfs.age_buffer_centisecs = 500 fs.xfs.filestream_centisecs = 500 (The file system is mounted with options "defaults,relatime") You wouldn't expect files last modified more than 12 hours before the crash to be erased but that is what has just happened this Friday evening. Perhaps there is some care and feeding of XFS that I'm not doing? Should I be using xfs_repair? I expect I'll just switch to ext4. -- Anthony Shipman Mamas don't let your babies als(a)iinet.net.au grow up to be outsourced.

11 47

Re: Coincedence or scam.........
by Chris Samuel 07 Apr '12

07 Apr '12

Hi Lindsay, I'm sorry you feel this way about luv-main, may I instead suggest reframing the question? Rather than take this elsewhere the way to make this on topic may instead be to ask how to investigate the attachment safely under Linux to ascertain whether or not it is malicious and, if not malicious, learn what it actually is. Please don't take the criticism to heart, it's not personal, but born of experience of lists that have gotten mired in off-topic discussions. All the best, Chris (on a phone so excuse formatting)

4 4

Coincedence or scam.........
by Lindsay Sprinter 06 Apr '12

06 Apr '12

On the 4th of april I had a packaged dipatched from the UK order number #112460. Yesterday I received an email, address was to my mcmedia email account stating shipment number 2633 had been returned to the the FedEx office, "the reason incorrect deliver address, please print out invoice copy attached and collect the package at our office." The atttachment is an exe not a pdf or doc file. I will not normally run anthing sent to me un announced. Every other case something like this has occured one gets either a pdf or a doc file. My strong suspicion is this is a scam and the timing is just a coincidence..........a develish coincedence. Would it be worthwhile to contact the suppliers of my package. I have recieved other items in the past no problems. Lindsay

4 5

Re: Coincedence or scam.........
by Tony Langdon 06 Apr '12

06 Apr '12

At 01:35 PM 4/6/2012, Colin Fee wrote: >I can only agree with Jason, who was suggesting yu take to >luv-talk. It clearly states on the LUV website at ><http://luv.asn.au/mailinglists.html>http://luv.asn.au/mailinglists.html >the following uner Rules and Guidelines: > >"5. luv-main is for LUV- or Linux-related posts I agree. While the post was security related, it wasn't Linux or LUV related, so luv-talk was the place to raise it. Actually, luv-talk has been fairly quiet of late, and when a discussion that you're not interested in flares up, it shouldn't be too difficult to filter the offending thread. Yeah sometimes it's frustrating, but the rules are there for a reason. 73 de VK3JED / VK3IRL http://vkradio.com

1 0