Re: md autodetect only detects one disk in raid1

take a look at your mdadm.conf ... both on your root fs and in your initrd... look for a DEVICES line and make sure it says DEVICES partitions... anything else is likely to cause problems like below. also make sure each array is specified by UUID rather than device. and then rebuild your

Re: [rdiff-backup-users] More patches to get rdiff-backup working under cygwin/windows

On Fri, 26 Jan 2007, Marc Dyksterhouse wrote: http://www.visiwave.com/download/rdiff_backup/rpath.py.patch can you provide more information on why this is necessary? i'm assuming it's because cygwin/windows can't do an fsync in some situation... would it be possible to put another

Re: [rdiff-backup-users] Re: How to Escape Globbing Patterns?

On Mon, 22 Jan 2007, Dave Howorth wrote: Andrew Price wrote: On 12/01/07 11:57, Andrew Price wrote: I'm using --include-globbing-filelist. If I wanted to specify a file in a file list that has [] in the file name, e.g. myfile[foo].txt, how would I escape the square brackets so that

Re: why would EPIPE cause socket port to change?

On Tue, 23 Jan 2007, Rick Jones wrote: Herbert Xu wrote: Prior to the last write, the socket entered the CLOSED state meaning that the old port is no longer allocated to it. As a result, the last write operates on an unconnected socket which causes a new local port to be allocated as an

Re: why would EPIPE cause socket port to change?

On Tue, 23 Jan 2007, David Miller wrote: From: dean gaudet [EMAIL PROTECTED] Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST) libnss-ldap has some code which attempts to determine if its private socket has been trampled on in between calls to the library... and to do this it caches

Re: [patch] faster vgetcpu using sidt (take 2)

On Thu, 18 Jan 2007, Andi Kleen wrote: > > let me know what you think... thanks. > > It's ok, although I would like to have the file in a separate directory. cool -- do you have a directory in mind? and would you like this change as two separate patches or one combined patch? thanks -dean -

why would EPIPE cause socket port to change?

in the test program below the getsockname result on a TCP socket changes across a write which produces EPIPE... here's a fragment of the strace: getsockname(3, {sa_family=AF_INET, sin_port=htons(37636), sin_addr=inet_addr(127.0.0.1)}, [17863593746633850896]) = 0 ... write(3, hi!\n, 4)

Re: [patch] faster vgetcpu using sidt (take 2)

On Thu, 18 Jan 2007, Andi Kleen wrote: let me know what you think... thanks. It's ok, although I would like to have the file in a separate directory. cool -- do you have a directory in mind? and would you like this change as two separate patches or one combined patch? thanks -dean - To

Re: bad performance on RAID 5

On Wed, 17 Jan 2007, Sevrin Robstad wrote: I'm suffering from bad performance on my RAID5. a echo check /sys/block/md0/md/sync_action gives a speed at only about 5000K/sec , and HIGH load average : # uptime 20:03:55 up 8 days, 19:55, 1 user, load average: 11.70, 4.04, 1.52 iostat

Re: raid5 software vs hardware: parity calculations?

On Mon, 15 Jan 2007, Robin Bowes wrote: I'm running RAID6 instead of RAID5+1 - I've had a couple of instances where a drive has failed in a RAID5+1 array and a second has failed during the rebuild after the hot-spare had kicked in. if the failures were read errors without losing the entire

Re: raid5 software vs hardware: parity calculations?

On Mon, 15 Jan 2007, berk walker wrote: dean gaudet wrote: echo check /sys/block/mdX/md/sync_action it'll read the entire array (parity included) and correct read errors as they're discovered. Could I get a pointer as to how I can do this check in my FC5 [BLAG] system? I can find

Re: raid5 software vs hardware: parity calculations?

On Mon, 15 Jan 2007, Mr. James W. Laferriere wrote: Hello Dean , On Mon, 15 Jan 2007, dean gaudet wrote: ...snip... it should just be: echo check /sys/block/mdX/md/sync_action if you don't have a /sys/block/mdX/md/sync_action file then your kernel is too old... or you

Bug#406949: reduce cron job noise

Package: htdig Version: 1:3.2.0b6-3 i'd rather not get this message every day from cron: /etc/cron.daily/htdig: /etc/cron.daily/htdig: line 22: 1723 Terminated lockfile-touch /var/run/htdig.cron the patch below should quiet things. -dean --- etc/cron.daily/htdig.dpkg-orig

Bug#406949: reduce cron job noise

Package: htdig Version: 1:3.2.0b6-3 i'd rather not get this message every day from cron: /etc/cron.daily/htdig: /etc/cron.daily/htdig: line 22: 1723 Terminated lockfile-touch /var/run/htdig.cron the patch below should quiet things. -dean --- etc/cron.daily/htdig.dpkg-orig

Re: [patch] faster vgetcpu using sidt (take 2)

On Sat, 13 Jan 2007, dean gaudet wrote: > ok here is the latest rev of this patch (against 2.6.20-rc4). > > timings in cycles: > > baseline patchedbaseline patched > no cache no cachecache cache > k8 pre-revF21

Re: [patch] faster vgetcpu using sidt (take 2)

On Sat, 13 Jan 2007, dean gaudet wrote: ok here is the latest rev of this patch (against 2.6.20-rc4). timings in cycles: baseline patchedbaseline patched no cache no cachecache cache k8 pre-revF2116 1417

Bug#406925: airmon-ng script depends on wireless-tools

Package: aircrack-ng Version: 1:0.6.2-6 the aircrack-ng should Depend on the wireless-tools package... since the airmon-ng script requires iwpriv/iwconfig. thanks -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [rdiff-backup-users] OverflowError reading get_sigs() response in very large tree

i wonder why i don't have this problem on million+ inode systems... i've had it working with python2.3 before too (although i'm using 2.4 now)... i'm still on 1.0.x. is there a 32/64-bit mismatch between your hosts? any chance there's some bug in that? -dean On Sat, 13 Jan 2007, Charles

[patch] faster vgetcpu using sidt (take 2)

cts if 0x1000 + (CONFIG_NR_CPUS<http://arctic.org/~dean/vgetcpu/> -dean Signed-off-by: dean gaudet <[EMAIL PROTECTED]> Index: linux/arch/x86_64/kernel/time.c === --- linux.orig/arch/x86_64/kernel/time.c2007-01-13

Re: raid5 software vs hardware: parity calculations?

On Sat, 13 Jan 2007, Robin Bowes wrote: Bill Davidsen wrote: There have been several recent threads on the list regarding software RAID-5 performance. The reference might be updated to reflect the poor write performance of RAID-5 until/unless significant tuning is done. Read that as

[patch] faster vgetcpu using sidt (take 2)

*nodes, but i'll let someone else handle that case ;). given this is a compile-time choice, and rdtscp is always slower than sidt, i've dropped the vgetcpu_mode variable. timing tools and test case can be found at http://arctic.org/~dean/vgetcpu/ -dean Signed-off-by: dean gaudet [EMAIL PROTECTED

[patch] add IP TOS support

i'd like to port mod_iptos to 2.x http://arctic.org/~dean/mod_iptos/... and i need apr_socket_opt_set support for IP_TOS. so here's a patch. sorry it's against 1.2.7 but that's what debian is still using. i'm sure there'll be feedback and i'll rebase against whatever you want after feedback.

porting mod_iptos to 2.x

i'd like to port mod_iptos to 2.x http://arctic.org/~dean/mod_iptos/ ... and preferably have it accepted into the main distribution. in 1.3.x it was trivial to do mod_iptos as a module because all i had to do was setsockopt(r-connection-client-fd, IPPROTO_IP, IP_TOS, ...). i've already sent a

Re: raid5 software vs hardware: parity calculations?

On Thu, 11 Jan 2007, James Ralston wrote: I'm having a discussion with a coworker concerning the cost of md's raid5 implementation versus hardware raid5 implementations. Specifically, he states: The performance [of raid5 in hardware] is so much better with the write-back caching on the

Re: O_DIRECT question

On Thu, 11 Jan 2007, Linus Torvalds wrote: > On Thu, 11 Jan 2007, Viktor wrote: > > > > OK, madvise() used with mmap'ed file allows to have reads from a file > > with zero-copy between kernel/user buffers and don't pollute cache > > memory unnecessarily. But how about writes? How is to do

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Thu, 11 Jan 2007, Andrew Morton wrote: > On Thu, 11 Jan 2007 03:04:00 -0800 (PST) > dean gaudet <[EMAIL PROTECTED]> wrote: > > > On Tue, 9 Jan 2007, Neil Brown wrote: > > > > > Imagine a machine with lots of memory - say 100Gig. > > > > i've h

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Tue, 9 Jan 2007, Neil Brown wrote: > Imagine a machine with lots of memory - say 100Gig. i've had these problems on machines as "small" as 8GiB. the real problem is that the kernel will let millions of potential (write) IO ops stack up for a device which can handle only mere 100s of IOs

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Tue, 9 Jan 2007, Neil Brown wrote: Imagine a machine with lots of memory - say 100Gig. i've had these problems on machines as small as 8GiB. the real problem is that the kernel will let millions of potential (write) IO ops stack up for a device which can handle only mere 100s of IOs per

Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines

On Thu, 11 Jan 2007, Andrew Morton wrote: On Thu, 11 Jan 2007 03:04:00 -0800 (PST) dean gaudet [EMAIL PROTECTED] wrote: On Tue, 9 Jan 2007, Neil Brown wrote: Imagine a machine with lots of memory - say 100Gig. i've had these problems on machines as small as 8GiB. the real

Re: O_DIRECT question

On Thu, 11 Jan 2007, Linus Torvalds wrote: On Thu, 11 Jan 2007, Viktor wrote: OK, madvise() used with mmap'ed file allows to have reads from a file with zero-copy between kernel/user buffers and don't pollute cache memory unnecessarily. But how about writes? How is to do zero-copy

Re: [patch] faster vgetcpu using sidt

On Sat, 6 Jan 2007, dean gaudet wrote: > below is a patch which improves vgetcpu latency on all x86_64 > implementations i've tested. > > Nathan Laredo pointed out the sgdt/sidt/sldt instructions are > userland-accessible and we could use their limit fields to tuck away a few

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Mon, 8 Jan 2007, H. Peter Anvin wrote: > I *definitely* support the concept that RDPMC 0 should could CPU cycles by > convention in Linux. unfortunately that'd be very limiting and annoying on core2 processors which have dedicated perf counters for clocks unhalted (actual vs. nominal), but

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Fri, 5 Jan 2007, Jan Engelhardt wrote: > > On Jan 4 2007 17:48, H. Peter Anvin wrote: > > > >[i386] All Transmeta CPUs have constant TSCs > >All Transmeta CPUs ever produced have constant-rate TSCs. > > A TSC is ticking according to the CPU frequency, is not it? transmeta decided years

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Fri, 5 Jan 2007, Jan Engelhardt wrote: On Jan 4 2007 17:48, H. Peter Anvin wrote: [i386] All Transmeta CPUs have constant TSCs All Transmeta CPUs ever produced have constant-rate TSCs. A TSC is ticking according to the CPU frequency, is not it? transmeta decided years before intel

Re: [PATCH] All Transmeta CPUs have constant TSCs

On Mon, 8 Jan 2007, H. Peter Anvin wrote: I *definitely* support the concept that RDPMC 0 should could CPU cycles by convention in Linux. unfortunately that'd be very limiting and annoying on core2 processors which have dedicated perf counters for clocks unhalted (actual vs. nominal), but

Re: [patch] faster vgetcpu using sidt

On Sat, 6 Jan 2007, dean gaudet wrote: below is a patch which improves vgetcpu latency on all x86_64 implementations i've tested. Nathan Laredo pointed out the sgdt/sidt/sldt instructions are userland-accessible and we could use their limit fields to tuck away a few bits of per-cpu

Bug#315547: [patch] stop fd leak in libnss-ldap

i believe these 3 bugs are the same problem. when the ldap server closes the connection during a response, libnss-ldap doesn't really notice at all... it returns an error code to the caller but doesn't pay attention to the error code itself. then nscd (or whatever other caller is involved)

Bug#315547: [patch] stop fd leak in libnss-ldap

i believe these 3 bugs are the same problem. when the ldap server closes the connection during a response, libnss-ldap doesn't really notice at all... it returns an error code to the caller but doesn't pay attention to the error code itself. then nscd (or whatever other caller is involved)

Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

On Wed, 3 Jan 2007, Andrew Morton wrote: > On Wed, 03 Jan 2007 22:56:07 -0800 (PST) > David Miller <[EMAIL PROTECTED]> wrote: > > > Note that the original rtorrent debian bug report was against 2.6.18 > > I think that was 2.6.18+debian-added-dirty-page-tracking-patches. i've seen it on a

Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

On Wed, 3 Jan 2007, Andrew Morton wrote: On Wed, 03 Jan 2007 22:56:07 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: Note that the original rtorrent debian bug report was against 2.6.18 I think that was 2.6.18+debian-added-dirty-page-tracking-patches. i've seen it on a 2.6.18.4 box

[patch] faster vgetcpu using sidt

compile time this patch detects if 0x1000 + (CONFIG_NR_CPUS<http://arctic.org/~dean/vgetcpu/> -dean Signed-off-by: dean gaudet <[EMAIL PROTECTED]> Index: linux/arch/x86_64/kernel/time.c === --- linux.orig/arch/x86_64/kernel/ti

[patch] faster vgetcpu using sidt

i'll be amazed if this isn't a huge win on p4. timing tools and test case can be found at http://arctic.org/~dean/vgetcpu/ -dean Signed-off-by: dean gaudet [EMAIL PROTECTED] Index: linux/arch/x86_64/kernel/time.c === --- linux.orig

Re: [openssl.org #1447] [bug] 0.9.8d: rc4 cpuid test broken on dual core cpus

On Fri, 5 Jan 2007, Andy Polyakov wrote: there is a cpuid test in rc4_skey.c which tests the hyperthreading cpuid bit to distinguish between two implementations of rc4... unfortunately this fails to properly distinguish the cpus. all dual core cpus (intel or amd) report HT support even

Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?

On Sat, 30 Dec 2006, Denis Vlasenko wrote: > I was experimenting with SSE[2] clear_page() which uses > non-temporal stores. That one requires 16 byte alignment. > > BTW, it worked ~300% faster than memset. But Andi Kleen > insists that cache eviction caused by NT stores will make it > slower in

Re: replace memset(...,0,PAGE_SIZE) calls with clear_page()?

On Sat, 30 Dec 2006, Denis Vlasenko wrote: I was experimenting with SSE[2] clear_page() which uses non-temporal stores. That one requires 16 byte alignment. BTW, it worked ~300% faster than memset. But Andi Kleen insists that cache eviction caused by NT stores will make it slower in

Bug#386357: please use -DUNALIGNED_OK on amd64

On Mon, 1 Jan 2007, Mark Brown wrote: On Wed, Sep 06, 2006 at 05:51:39PM -0700, dean gaudet wrote: note that this define wasn't necessary on 32-bit x86 because there's custom 32-bit assembly which uses unaligneds even more aggressively than the C code does even when given UNALIGNED_OK

Bug#386357: please use -DUNALIGNED_OK on amd64

On Mon, 1 Jan 2007, dean gaudet wrote: and i can't even reproduce my results... here's the averages of the user cpu seconds for 10 runs of minizip -9o a.zip linux-2.6.19.tar: baseline -DUNALIGNED_OK k8 revF26.62 26.59 core2 28.43 28.44 you know, gzip -9

TCP_DEFER_ACCEPT brokenness?

hi... i'm having troubles matching up the tcp(7) man page description of TCP_DEFER_ACCEPT versus some comments in the kernel (2.6.20-rc2) versus how the kernel actually acts. the man page says this: TCP_DEFER_ACCEPT Allows a listener to be awakened only when data arrives on

Re: [rdiff-backup-users] [PATCH] Preserve symlink permissions

On Fri, 29 Dec 2006, Andrew Ferguson wrote: dean gaudet wrote: btw -- adding two syscalls per symlink creation is a bit of a waste for platforms where it doesn't matter. any chance you'd consider adding a test to fs_abilities and conditionalizing on it? Dean, I have added

[openssl.org #1447] [bug] 0.9.8d: rc4 cpuid test broken on dual core cpus

there is a cpuid test in rc4_skey.c which tests the hyperthreading cpuid bit to distinguish between two implementations of rc4... unfortunately this fails to properly distinguish the cpus. all dual core cpus (intel or amd) report HT support even if they don't use symmetric-multithreading

[patch] ifb double-counts packets

it seems that ifb counts packets twice... both at xmit time and also in the tasklet. i'm not sure which one of the two to drop, but here's a patch for dropping the counting at xmit time. patch against 2.6.20-rc1. -dean Signed-off-by: dean gaudet [EMAIL PROTECTED] Index: linux/drivers/net

Re: [patch] ifb double-counts packets

On Sat, 23 Dec 2006, jamal wrote: On Sat, 2006-23-12 at 02:35 -0800, dean gaudet wrote: it seems that ifb counts packets twice... both at xmit time and also in the tasklet. i'm not sure which one of the two to drop, but here's a patch for dropping the counting at xmit time. Good

Re: 2.6.19 file content corruption on ext3

On Mon, 18 Dec 2006, Linus Torvalds wrote: > On Tue, 19 Dec 2006, Nick Piggin wrote: > > > > We never want to drop dirty data! (ignoring the truncate case, which is > > handled privately by truncate anyway) > > Bzzt. > > SURE we do. > > We absolutely do want to drop dirty data in the writeout

Re: 2.6.19 file content corruption on ext3

On Mon, 18 Dec 2006, Linus Torvalds wrote: On Tue, 19 Dec 2006, Nick Piggin wrote: We never want to drop dirty data! (ignoring the truncate case, which is handled privately by truncate anyway) Bzzt. SURE we do. We absolutely do want to drop dirty data in the writeout path. How

Re: [LARTC] Per-process QoS on Linux?

i use a mixture of multiple IP addrs and IPTOS (see http://arctic.org/~dean/mod_iptos/ for an apache 1.3.x module to set IPTOS on a per response basis). but for uid specifically you can also use iptables blahblah -m owner --uid-owner $uid -j MARK --set-mark N and then match the mark with tc.

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Thu, 14 Dec 2006, Jan Beulich wrote: > >with the patch it boots perfectly without any command-line args. > > Are you getting the 'Firmware space is locked read-only' message then? yep... so let me ask a naive question... don't we want the firmware locked read-only because that protects the

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Thu, 14 Dec 2006, Jan Beulich wrote: with the patch it boots perfectly without any command-line args. Are you getting the 'Firmware space is locked read-only' message then? yep... so let me ask a naive question... don't we want the firmware locked read-only because that protects the

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 13 Dec 2006, Chris Wright wrote: > * dean gaudet ([EMAIL PROTECTED]) wrote: > > just for the public record (i already communicated with Jan in private > > mail on this one)... i have a box which hangs hard starting at 2.6.18.2 > > and 2.6.19 -- hangs hard during t

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 29 Nov 2006, Jan Beulich wrote: > >>> Dave Jones <[EMAIL PROTECTED]> 24.11.06 21:27 >>> > >On Wed, Nov 22, 2006 at 08:53:08AM +0100, Jan Beulich wrote: > > > >It does appear to work w/out the patch. I've asked for a small bit > > > >of diagnostics (below), perhaps you've got something

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 29 Nov 2006, Jan Beulich wrote: Dave Jones [EMAIL PROTECTED] 24.11.06 21:27 On Wed, Nov 22, 2006 at 08:53:08AM +0100, Jan Beulich wrote: It does appear to work w/out the patch. I've asked for a small bit of diagnostics (below), perhaps you've got something you'd rather see?

Re: [stable] [PATCH 46/61] fix Intel RNG detection

On Wed, 13 Dec 2006, Chris Wright wrote: * dean gaudet ([EMAIL PROTECTED]) wrote: just for the public record (i already communicated with Jan in private mail on this one)... i have a box which hangs hard starting at 2.6.18.2 and 2.6.19 -- hangs hard during the intel hw rng tests

Re: Shrinking a RAID1--superblock problems

On Tue, 12 Dec 2006, Jonathan Terhorst wrote: I need to shrink a RAID1 array and am having trouble with the persistent superblock; namely, mdadm --grow doesn't seem to relocate it. If I downsize the array and then shrink the corresponding partitions, the array fails since the superblock

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: > On Mon, Dec 11, 2006 at 01:17:25PM -0800, dean gaudet wrote: > > rdtscp doesn't solve anything extra [..] > > [..] lsl-based vgetcpu is relatively slow > > Well, if you accept to run slow there's nothing to solve in the

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: > As far as I can see, many changes happened but nobody has yet added > the rdtscp support to x86-64. rdtscp finally solves the problem and it > obsoletes hpet for timekeeping and it allows a fully userland > gettimeofday running at maximum speed in

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: As far as I can see, many changes happened but nobody has yet added the rdtscp support to x86-64. rdtscp finally solves the problem and it obsoletes hpet for timekeeping and it allows a fully userland gettimeofday running at maximum speed in

Re: rdtscp vgettimeofday

On Mon, 11 Dec 2006, Andrea Arcangeli wrote: On Mon, Dec 11, 2006 at 01:17:25PM -0800, dean gaudet wrote: rdtscp doesn't solve anything extra [..] [..] lsl-based vgetcpu is relatively slow Well, if you accept to run slow there's nothing to solve in the first place indeed. If nothing

Bug#390038: this is caused by the use of /sbin/update-grub

On Sun, 3 Dec 2006, Frans Pop wrote: On Sunday 03 December 2006 22:34, dean gaudet wrote: the linux-image .postrm script is (through some mechanism) invoking /sbin/update-grub. /sbin/update-grub gives a warning now: You shouldn't call /sbin/update-grub. Please call /usr/sbin/update

Bug#390038: this is caused by the use of /sbin/update-grub

the linux-image .postrm script is (through some mechanism) invoking /sbin/update-grub. /sbin/update-grub gives a warning now: You shouldn't call /sbin/update-grub. Please call /usr/sbin/update-grub instead! except that warning is sent on stdout. stdout in the .postrm script is hooked up

Bug#390038: this is caused by the use of /sbin/update-grub

On Sun, 3 Dec 2006, Frans Pop wrote: On Sunday 03 December 2006 22:34, dean gaudet wrote: the linux-image .postrm script is (through some mechanism) invoking /sbin/update-grub. /sbin/update-grub gives a warning now: You shouldn't call /sbin/update-grub. Please call /usr/sbin/update

Re: Observations of a failing disk

On Tue, 28 Nov 2006, Richard Scobie wrote: Anyway, my biggest concern is why echo repair /sys/block/md5/md/sync_action appeared to have no effect at all, when I understand that it should re-write unreadable sectors? i've had the same thing happen on a seagate 7200.8 pata 400GB... and

Re: gratuitous arp

On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all

gratuitous arp

hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took forever to timeout the ARP entries for interface aliases). so i set about looking to see why that wasn't happening. i either missed it, or

Re: gratuitous arp

On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took forever to timeout the ARP entries for interface aliases). so i

Re: [rdiff-backup-users] What happens when you move files around?

as a one time hack, if you want to reduce the network bandwidth required to move the 1GB file you could hardlink the oldfile to the newfile (and leave the oldfile around for now) and then do a backup... rdiff-backup will detect the hardlink and just hardlink the destination file in the mirror

Re: Raid 1 (non) performance

On Wed, 15 Nov 2006, Magnus Naeslund(k) wrote: # cat /proc/mdstat Personalities : [raid1] md2 : active raid1 sda3[0] sdb3[1] 236725696 blocks [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 4192896 blocks [2/2] [UU] md0 : active raid1 sda1[0] sdb1[1] 4192832 blocks

Re: safest way to swap in a new physical disk

On Tue, 14 Nov 2006, Will Sheffler wrote: Hi. What is the safest way to switch out a disk in a software raid array created with mdadm? I'm not talking about replacing a failed disk, I want to take a healthy disk in the array and swap it for another physical disk. Specifically, I have an

Bug#355178: [#355178] unable to reproduce the 4GB librsync1 problem

On Sat, 18 Nov 2006, Michael Prokop wrote: So can you please provide the necessary steps to reproduce the problem? iirc it doesn't happen on every file 4GB. try between a 32-bit and a 64-bit host -- that's when it was hitting me the worst. -dean -- To UNSUBSCRIBE, email to [EMAIL

Bug#399271: post(8) segfaulting

Package: nmh Version: 1.2-1 in 1.2-1 post(8) is segfaulting (amd64)... doesn't happen with same config on 1.1-release-4. if i get a chance i'll grab a gdb backtrace... but maybe this strace will help. oh maybe my mts.conf will help too: # grep -ve '^#.*' -e '^$' /etc/nmh/mts.conf mts: smtp

Re: [rdiff-backup-users] Suggestion for documentation change

On Sat, 18 Nov 2006, Andrew Ferguson wrote: dean gaudet wrote: sounds like the bug is that rdiff-backup decides there's a metadata change and stores an almost-empty .diff.gz file even though it's not required. even though the metadata change is innocuous... I think there could

Re: [rdiff-backup-users] Suggestion for documentation change

On Sat, 18 Nov 2006, dean gaudet wrote: yep -- but we could store an actual 0-length file instead... so we're not wasting an entire disk block on many filesystems. better to name it .nodiff or something else so we can distinguish between an incompletely written .diff.gz and a file

Re: [rdiff-backup-users] [PATCH] Log symlink creation

On Thu, 16 Nov 2006, Gordon Rowell wrote: Has anyone looked at storing symlink metadata separately for filesystems which don't support symlinks? In particular, when backing up to a CIFS fileystem. This currently logs a SpecialFileError, which is not surprising. yeah it would be desirable to

RE: touch_cache() only touches two thirds

On Fri, 17 Nov 2006, dean gaudet wrote: > another pointer chase arranged to fill the L1 (or L2) using many many > pages. i.e. suppose i wanted to traverse 32KiB L1 with 64B cache lines > then i'd allocate 512 pages and put one line on each page (pages ordered > randomly), but co

RE: touch_cache() only touches two thirds

On Fri, 10 Nov 2006, Bela Lubkin wrote: > The corrected code in > covers the full cache range. Granted that modern CPUs may be able to track > multiple simultaneous cache access streams: how many such streams are they > likely to be able to

Re: How to interpret MCE messages?

On Wed, 15 Nov 2006, martin f krafft wrote: > Thus I guess the CPU is asking for retirement. I am just > double-checking with you guys whether I can be sure that it's only > the CPU, or whether it could also be the fault of the motherboard... could be VRMs and/or PSU delivering unclean power...

Re: How to interpret MCE messages?

On Wed, 15 Nov 2006, martin f krafft wrote: Thus I guess the CPU is asking for retirement. I am just double-checking with you guys whether I can be sure that it's only the CPU, or whether it could also be the fault of the motherboard... could be VRMs and/or PSU delivering unclean power... but

RE: touch_cache() only touches two thirds

On Fri, 10 Nov 2006, Bela Lubkin wrote: The corrected code in http://bugzilla.kernel.org/show_bug.cgi?id=7476#c4 covers the full cache range. Granted that modern CPUs may be able to track multiple simultaneous cache access streams: how many such streams are they likely to be able to follow

RE: touch_cache() only touches two thirds

On Fri, 17 Nov 2006, dean gaudet wrote: another pointer chase arranged to fill the L1 (or L2) using many many pages. i.e. suppose i wanted to traverse 32KiB L1 with 64B cache lines then i'd allocate 512 pages and put one line on each page (pages ordered randomly), but colour them so

Re: [rdiff-backup-users] Suggestion for documentation change

sounds like the bug is that rdiff-backup decides there's a metadata change and stores an almost-empty .diff.gz file even though it's not required. even though the metadata change is innocuous... seems like it would be possible to at least avoid the almost-empty patch file when there is a

Re: [rdiff-backup-users] [PATCH] rdiff-backup.spec cleanups

commited, thanks. -dean On Thu, 16 Nov 2006, Gordon Rowell wrote: - Adjust URLs - Add changelog entries It's a pity there is an Epoch: 0 header in the SPEC files as an Epoch of zero outvotes no Epoch. I'd be tempted to delete those headers and let RPM versioning work normally. However,

Re: raid5 hang on get_active_stripe

and i haven't seen it either... neil do you think your latest patch was hiding the bug? 'cause there was an iteration of an earlier patch which didn't produce much spam in dmesg but the bug was still there, then there is the version below which spams dmesg a fair amount but i didn't see the

Re: [rdiff-backup-users] --check-destination-dir fails after a crash (redux)

as i mentioned at some other point when this was asked... i'm really not 100% certain that change is the right change... that's why i never applied it to cvs. maybe someone could look at it more closely? -dean On Wed, 15 Nov 2006, Gordon Rowell wrote: Gordon Rowell wrote: Bumping this

Bug#398312: INITRDSTART='none' doesn't work

On Mon, 13 Nov 2006, martin f krafft wrote: severity 398312 important tags 398312 unreproducible moreinfo thanks even though i have INITRDSTART='none' in my /etc/default/mdadm and rebuilt the initrd, it still goes and does array discovery at boot time. piper:/tmp/cdt.d.Ns8889# grep

Bug#398312: Re: Bug#398312: INITRDSTART='none' doesn't work

On Mon, 13 Nov 2006, martin f krafft wrote: also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1107 +0100]: which causes the is_true() in info() to return 1 which causes the set -e to terminate the script. What shell are you using? my SHELL=/bin/zsh, but that won't affect the script

Bug#398310: Re: Bug#398310: don't assemble all arrays on install

On Mon, 13 Nov 2006, martin f krafft wrote: also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1116 +0100]: right, now i know that i should create an /etc/default/mdadm *before* i install mdadm... because unlike other packages, mdadm does potentially dangerous things just by installing

Bug#398347: hooks should respect run-parts naming conventions

Package: initramfs-tools Version: 0.85a the run_scripts() function should respect the same naming conventions as run-parts(8) ... in particular if my editor creates foo~, foo.bak, .foo.swp files run_scripts() will try to run them. ditto for foo,v. run_scripts() should also not attempt to

Bug#398310: don't assemble all arrays on install

On Mon, 13 Nov 2006, martin f krafft wrote: severity 398310 important retitle 398310 let user choose when to start which array tags 398310 confirmed help thanks also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.0230 +0100]: i had 4 disks which i had experimented with sw raid10

Bug#398347: hooks should respect run-parts naming conventions

Package: initramfs-tools Version: 0.85a the run_scripts() function should respect the same naming conventions as run-parts(8) ... in particular if my editor creates foo~, foo.bak, .foo.swp files run_scripts() will try to run them. ditto for foo,v. run_scripts() should also not attempt to

Bug#398310: don't assemble all arrays on install

Package: mdadm Version: 2.5.5-1 Severity: grave it's dangerous to generate an mdadm.conf and start running arrays automatically at install time! i nearly got bit by this. i marked this grave because there's a potential for data loss with the current install scripts. i had 4 disks which i had

Bug#398312: INITRDSTART='none' doesn't work

Package: mdadm Version: 2.5.5-1 Severity: grave even though i have INITRDSTART='none' in my /etc/default/mdadm and rebuilt the initrd, it still goes and does array discovery at boot time. this is marked grave because it can cause dataloss if drives with stale superblocks are put together in an

[rdiff-backup-users] rdiff-backup 1.1.7 released

fixes the OSX showstopper in 1.1.6. http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.1.7.tar.gz i have to admit, i haven't tested these releases... but i'm still of the opinion it's better for me to commit / release than it is to just let things stagnate :) -dean New in v1.1.7

<    1   2   3   4   5   6   7   8   9   10   >