Re: [rdiff-backup-users] problem with chmod 0 directories

On Mon, 15 May 2006, The Anarcat wrote: > Hello, > > I have a problem running rdiff-backup over a directory which has a mode > of 0. The source directory is read as root so that poses no problem, but > the target directory is written as a regular user, so I get a: > > File "/usr/lib/python2.3/

Re: [rdiff-backup-users] Warning, metadata file has entry for ...

On Fri, 12 May 2006, Chris Wilson wrote: > > in set_regress_inc > >assert len(newer_incs) <= 1, "Too many recent increments" > > AssertionError: Too many recent increments try running with -v5 or maybe even higher and see if you can figure out where it's finding more increments than it's exp

Re: raid5 hang on get_active_stripe

On Tue, 14 Mar 2006, Neil Brown wrote: > On Monday March 13, [EMAIL PROTECTED] wrote: > > Hi all, > > > > I just experienced some kind of lockup accessing my 8-drive raid5 > > (2.6.16-rc4-mm2). The system has been up for 16 days running fine, but > > now processes that try to read the md device h

Re: [rdiff-backup-users] librsync errors while running a backup

On Sat, 6 May 2006, dave kempe wrote: > Jason Faulkner wrote: > > We are using rdiff-backup version 0.13.4-5 on Debian Sarge. > > > > Thanks for any suggestions. > > > > Hi, yeah you need to upgrade rdiff-backup to a newer version and get the > latest librsync from cvs. I am not sure any relea

Bug#364527: really support large files

Package: vorbis-tools Version: 1.1.1-5 hi... thanks for trying to fix bug#359068 ... but unfortunately your fix didn't work :) i think after seeing the patches below you might want to consider the easy fix i suggested in the bug... changing CFLAGS directly. there are a few problems... one is t

proactive raid5 disk replacement success (using bitmap + raid1)

i had a disk in a raid5 which i wanted to clone onto the hot spare... without going offline and without long periods without redundancy. a few folks have discussed using bitmaps and temporary (superblockless) raid1 mappings to do this... i'm not sure anyone has tried / reported success though.

Bug#361674: please do not use mdrun at all

mdrun does not respect the device minor numbers at all... this can totally mess up the ordering of md devices and screw with static mounts (note that while mounting by label/uuid is preferable it isn't always available -- for example XFS external log partitions cannot be specified by label or u

Bug#361674: please do not use mdrun at all

mdrun does not respect the device minor numbers at all... this can totally mess up the ordering of md devices and screw with static mounts (note that while mounting by label/uuid is preferable it isn't always available -- for example XFS external log partitions cannot be specified by label or u

Re: [rdiff-backup-users] Re: bug or user-error? killed my whole repository today just by doing some restore-tests....

On Thu, 13 Apr 2006, roland wrote: > maybe my posting is relatet to this one ? > > http://lists.gnu.org/archive/html/rdiff-backup-users/2004-09/msg00019.html that was solved in 0.13.6... from the change log: |** Serious bug fix ** |If a directory in the source direct

Bug#351183: use "mdadm -Ac partitions --uuid FOO" to assemble root raid

On Fri, 24 Feb 2006, Jason Boxman wrote: > I tired it, but on my system I get a segmentation fault from mdadm when it > tried to assemble. Assembling with the usual > > `mdadm --assemble /dev/md0 /dev/hde1 /dev/hdg1` works. > > [EMAIL PROTECTED]:~$ uname -a > Linux faith 2.6.16-rc3-20060212 #1

Re: [rdiff-backup-users] RDiff backup ignoring two files

try with -v4 or -v5 maybe? it might show something more interesting... btw there have been some recent bugfixes in librsync w.r.t. hanging on large files... which doesn't sound like your problem, but is related. -dean On Tue, 11 Apr 2006, Jason Faulkner wrote: > Hi, I'm using rdiff-backup to

forcing a read on a known bad block

hey Neil... i've been wanting to test out the reconstruct-on-read-error code... and i've had two chances to do so, but haven't be able to force md to read the appropriate block to trigger the code. i had two disks with SMART Current_Pending_Sector > 0 (which indicates pending read error) and i

Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11

On Mon, 10 Apr 2006, Marc L. de Bruin wrote: > dean gaudet wrote: > > On Mon, 10 Apr 2006, Marc L. de Bruin wrote: > > > > > However, all "preferred minor"s are correct, meaning that the output is in > > > sync with what I expected it to be from /e

Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11

On Mon, 10 Apr 2006, Marc L. de Bruin wrote: > However, all "preferred minor"s are correct, meaning that the output is in > sync with what I expected it to be from /etc/mdadm/mdadm.conf. > > Any other ideas? Just adding /etc/mdadm/mdadm.conf to the initrd does not seem > to work, since mdrun seem

Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11

On Mon, 10 Apr 2006, Marc L. de Bruin wrote: > dean gaudet wrote: > > > initramfs-tools generates an "mdrun /dev" which starts all the raids it can > > find... but does not include the mdadm.conf in the initrd so i'm not sure it > > will necessarily star

Bug#361674: problems with using "mdrun /dev"

Package: initramfs-tools Version: 0.59b hi... if you're going to use "mdrun /dev" and launch all arrays during the initrd then you should also include mdadm.conf -- because otherwise you may end up starting arrays on the wrong minors... or even worse, if someone is using partitioned md then you

Bug#361674: problems with using "mdrun /dev"

Package: initramfs-tools Version: 0.59b hi... if you're going to use "mdrun /dev" and launch all arrays during the initrd then you should also include mdadm.conf -- because otherwise you may end up starting arrays on the wrong minors... or even worse, if someone is using partitioned md then you

Re: [rdiff-backup-users] Re: --help ?

On Sat, 8 Apr 2006, [EMAIL PROTECTED] wrote: > hello ! > > i like rdiff-backup very much - but - why the heck doesn`t it follow unix > commandline options "standards" ? > > #rdiff-backup --help > Fatal Error: Bad commandline options: option --help not recognized > See the rdiff-backup manual

Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11

On Sun, 9 Apr 2006, Marc L. de Bruin wrote: ... > Okay, just pressing Control-D continues the boot process and AFAIK the root > filesystemen actually isn't corrupt. Running e2fsck returns no errors and > booting 2.6.11 works just fine, but I have no clue why it picked the wrong > partitions to bui

Bug#361444: dangling symlinks

Package: graphviz Version: 2.8-1 hey there... there are some dangling symlinks in the graphviz package: /usr/lib/graphviz/lua/gv.so -> libgv_lua.so /usr/lib/graphviz/perl/gv.so -> libgv_perl.so /usr/lib/graphviz/python/_gv.so -> libgv_python.so /usr/lib/graphviz/ruby/gv.so -> libgv_ruby.so /usr/l

Re: [rdiff-backup-users] How to limit a restore to a single directory (without the subdirectories)

On Mon, 3 Apr 2006, Olaf Dabrunz wrote: > Hello, > > something accidentially deleted all files in a directory, but not the > subdirectories or any files in there. In other words, something did a > "rm -f dir/*" (non-recursive). > > before after > -- - > d

Re: raid5 high cpu usage during reads - oprofile results

On Sat, 1 Apr 2006, Alex Izvorski wrote: > On Sat, 2006-04-01 at 14:28 -0800, dean gaudet wrote: > > i'm guessing there's a good reason for STRIPE_SIZE being 4KiB -- 'cause > > otherwise it'd be cool to run with STRIPE_SIZE the same as your raid > &

Re: [rdiff-backup-users] Warning, metadata file has entry for ...

On Sat, 1 Apr 2006, Chris Wilson wrote: > Hi all, > > > On the machine where the disk filled up, I'm now getting the following > > errors every time I run a particular backup: > > > > Warning: Local version 1.0.1 does not match remote version 1.0.3. > > Previous backup seems to have failed, regr

Re: raid5 high cpu usage during reads - oprofile results

On Sat, 1 Apr 2006, Alex Izvorski wrote: > Dean - I think I see what you mean, you're looking at this line in the > assembly? > > 65830 16.8830 : c1f: cmp%rcx,0x28(%rax) yup that's the one... that's probably a fair number of cache (or tlb) misses going on right there. > I looked

Bug#359068: File too large

Package: vorbis-tools Version: 1.1.1-3 oggenc can't handle files >= 2GiB: ERROR: Cannot open input file "20060325-1959.wav": File too large -rw-r--r-- 1 dean music 2560491564 Mar 26 00:01 20060325-1959.wav fix is easy... add -D_FILE_OFFSET_BITS=64 to CFLAGS in debian/rules... i've test rebuilt

Re: raid5 high cpu usage during reads - oprofile results

On Sat, 25 Mar 2006, Alex Izvorski wrote: > http://linuxraid.pastebin.com/621363 - oprofile annotated assembly it looks to me like a lot of time is spent in __find_stripe() ... i wonder if the hash is working properly. in raid5.c you could try changing #define stripe_hash(conf, sect) (&((conf

Re: raid5 that used parity for reads only when degraded

On Thu, 23 Mar 2006, Alex Izvorski wrote: > Also the cpu load is measured with Andrew Morton's cyclesoak > tool which I believe to be quite accurate. there's something cyclesoak does which i'm not sure i agree with: cyclesoak process dirties an array of 100 bytes... so what you're really ge

Re: naming of md devices

On Thu, 23 Mar 2006, Nix wrote: > Last I heard the Debian initramfs constructs RAID arrays by explicitly > specifying the devices that make them up. This is, um, a bad idea: > the first time a disk fails or your kernel renumbers them you're > in *trouble*. yaird seems to dtrt ... at least in unst

Re: [rdiff-backup-users] Fatal Error: Bad rdiff-backup-data dir on destination side

On Wed, 22 Mar 2006, Noah wrote: > On Wed, 22 Mar 2006 06:56:20 -0800, Noah wrote > > I am hoping there is a way around starting the backup process over > > again. I had it running for about 6 hours and then the connection > > to my home server was lost. Any clues if there is anything I can d

Re: [rdiff-backup-users] Fatal Error: Bad rdiff-backup-data dir on destination side

On Wed, 22 Mar 2006, Noah wrote: > > I am hoping there is a way around starting the backup process over again. I > had it running for about 6 hours and then the connection to my home server > was lost. Any clues if there is anything I can do instead of completely > blowing away the rdiff-backu

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

On Mon, 20 Mar 2006, Sébastien Maret wrote: > On Mar 16, 2006, at 2:02, dean gaudet wrote: > > > On Thu, 16 Mar 2006, Sebastien Maret wrote: > > > > > File "/sw/lib/python2.4/site-packages/rdiff_backup/metadata.py", line > > >

Bug#357561: use setsid() to detach from controlling tty

Package: apache Version: 1.3.34-2 i'm not sure i understand the motivation behind patch 033_-F_NO_SETSID ... the problem in #244857 is a result of the following behaviour of setsid(2): On error, -1 is returned, and errno is set. The only error which can happen is EPERM. It is r

Bug#357561: use setsid() to detach from controlling tty

Package: apache Version: 1.3.34-2 i'm not sure i understand the motivation behind patch 033_-F_NO_SETSID ... the problem in #244857 is a result of the following behaviour of setsid(2): On error, -1 is returned, and errno is set. The only error which can happen is EPERM. It is r

Bug#357522: mime_magic warnings about application/x-awk

another workaround is to make a copy of /usr/share/file/magic.mime, i called mine /usr/share/file/magic.mime.php4 ... then comment out the awk regex line... then edit /etc/php4/apache/php.ini and somewhere in the [PHP] section add: mime_magic.magicfile = "/usr/share/file/magic.mime.php4" ... i

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

On Thu, 16 Mar 2006, Sebastien Maret wrote: > File "/sw/lib/python2.4/site-packages/rdiff_backup/metadata.py", line 378, > in __init__ > if compress and not rp_base.isinccompressed(): i think that line 378 in metadata.py needs to be: if compress and rp_base.isincfile() and not rp_base

Re: [rdiff-backup-users] CRC Check Failed

On Tue, 14 Mar 2006, Mike Bydalek wrote: > Here's the results of that: > > $ find server-root/rdiff-backup-data -type f -name \*.gz -print0 | xargs > -0r gzip --test > > gzip: > server-root/rdiff-backup-data/mirror_metadata.2006-03-12T21:46:00-07:00.snapshot.gz: > unexpected end of file > > Sho

Re: [rdiff-backup-users] CRC Check Failed

On Tue, 14 Mar 2006, dean gaudet wrote: > On Tue, 14 Mar 2006, Mike Bydalek wrote: > > > I've been trying to backup for a couple of days now and I'm having some > > problems that I cannot get around. For some reason, rdiff-backup dies > > while trying to rever

Re: [rdiff-backup-users] CRC Check Failed

On Tue, 14 Mar 2006, Mike Bydalek wrote: > I've been trying to backup for a couple of days now and I'm having some > problems that I cannot get around. For some reason, rdiff-backup dies > while trying to revert every single time. > > I've tried to delete the directory on both the server and the

Re: [rdiff-backup-users] Problem with backing up 0.13.4 to 1.1.5

On Mon, 13 Mar 2006, Alex Meaden wrote: > Warning Security Violation! > Bad request for function: fs_abilities.get_fsabilities_readwrite > with arguments: ['destination', 0xb7a1b5ac>, 1, None] i'm pretty sure that's fixed in 1.0.something... did you add --restrict-read-only to your .ssh/author

Bug#356550: gpg does not need to be setuid root any more

Package: gnupg Version: 1.4.2.2-1 mlock(2) is available to regular users since kernel 2.6.9... it would be cool if /usr/bin/gpg didn't install as setuid by default in that case -- perhaps by asking in a dialog if the admin wants it setuid or not. (i'm just using dpkg-statoverride for now, so i

Re: how to clone a disk

On Sat, 11 Mar 2006, Ming Zhang wrote: > On Sat, 2006-03-11 at 16:31 -0800, dean gaudet wrote: > > if you fail the disk from the array, or boot without the failing disk, > > then the event counter in the other superblocks will be updated... and the > > removed/failed d

Re: how to clone a disk

On Sat, 11 Mar 2006, Ming Zhang wrote: > On Sat, 2006-03-11 at 16:15 -0800, dean gaudet wrote: > > > you're planning to do this while the array is online? that's not safe... > > unless it's a read-only array... > > what i plan to do is to pull out the d

Re: how to clone a disk

On Sat, 11 Mar 2006, Ming Zhang wrote: > On Sat, 2006-03-11 at 06:53 -0500, Paul M. wrote: > > Since its raid5 you would be fine just pulling the disk out and > > letting the raid driver rebuild the array. If you have a hot spare > > yes, rebuilding is the simplest way. but rebuild will need to r

Re: [rdiff-backup-users] patch for plain tcp connection(for rdiff 1.0.4)

On Wed, 8 Mar 2006, catam wrote: > on local side: > # rdiff-backup --remote-schema "tcp:%s:499" 192.168.0.1::/etc backups/etc you could use netcat or similar tool... -dean ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://l

Re: [rdiff-backup-users] rdiff

On Wed, 1 Mar 2006, Brian C. Hill wrote: > ImportError: ld.so.1: /usr/pkg/python/bin/rdiff-backup: fatal: > librsync.so.1: open failed: No such file or directory > - > > What am I doing wrong? Is an old Python installation (th

Re: Auto-assembling arrays using mdadm

On Thu, 9 Mar 2006, Sean Puttergill wrote: > This is the kind of functionality provided by kernel > RAID autodetect. You don't have to have any config > information provided in advance. The kernel finds and > assembles all arrays on disks with RAID autodetect > partition type. I want to do the

Re: Auto-assembling arrays using mdadm

On Thu, 9 Mar 2006, Sean Puttergill wrote: > Hi. > > I am looking to script auto-assembly of all arrays > detected on an arbitrary set of drives using mdadm. > > The way I am thinking of doing this is as follows: > > mdadm.conf = > > DEVICE /dev/sd* i prefer to use "DEVICE partitions" > 1. U

Bug#355178: 'internal error: job made no progress' on 25G file

Package: librsync1 Version: 0.9.7-1 i wonder if you would consider applying this patch from upstream to fix problems which occur with files over 4GB. see: https://sourceforge.net/tracker/index.php?func=detail&aid=1439412&group_id=56125&atid=479441 and https://sourceforge.net/tracker/?func

Re: [tcpdump-workers] D_IN vs PCAP_D_IN

On Mon, 27 Feb 2006, Aaron Turner wrote: > Well looks like sometime in libpcap 0.9.x, pcap.h changed the enum for > direction_t to pcap_direction_t and the enumerated types within. > While I can understand the reason of the change, it's driving me nuts > since there doesn't seem to be an easy way

Re: [rdiff-backup-users] rdiff-backup/rsync +ssh performance comparison

On Mon, 6 Feb 2006, Vadim Kouzmine wrote: > Let me summarize the information I've gathered during my tests, on two > platforms (Gentoo, Trustix 2.2) and different versions of python (2.2.3, > 2.3.5, 2.4.2): > > - on 3GHz P4 Xeon I get ~2MB/s steady transfer through ssh, on P4 3GHz > it's ~1.9MB/s

Re: [rdiff-backup-users] How do i enable the remote schema to use blowfish ssh ?

On Mon, 20 Feb 2006, Robert Yoon wrote: > How do i enable the remote schema to use blowfish ssh ? > Since it is faster. i prefer to do that with .ssh/config... i go into lots of related details here: http://arctic.org/~dean/rdiff-backup/unattended.html > Also by disabling the statistics typ

Bug#351185: use ifrename -t

On Tue, 14 Feb 2006, Guus Sliepen wrote: > The manual page says this about the -t option: > > -t Enable name takeover support. [...] This works only with kernel > 2.6.X and if the other interface is down. Consequently, this is not > compatible with Hotplug. [...] In any case, name swapping an

Bug#353229: EDITMOTD=no means don't touch my motd, ever

Package: initscripts Version: 2.86.ds1-11 i have EDITMOTD=no in my /etc/default/rcS ... yet the new initscripts.postinst insists on turning my motd into a symlink. that counts as an edit in my books... please leave the file alone, period. thanks -dean -- To UNSUBSCRIBE, email to [EMAIL PROT

Re: [rdiff-backup-users] File change detection using hashes

On Mon, 13 Feb 2006, Wiebe Cazemier wrote: > Something _has_ to be devised to detect changes in files properly, to > avoid files not being backed up. Perhaps you could try to implement an > option for ctime checking, and possibly discover again why that's not > possible. If it _is_ impossible, my

Bug#351185: use ifrename -t

On Tue, 14 Feb 2006, Guus Sliepen wrote: > tags 351185 + wontfix > thanks > > On Thu, Feb 02, 2006 at 07:13:33PM -0800, dean gaudet wrote: > > > i think /etc/init.d/ifrename should use the -t option... which allows > > devices to take over already assigned de

Re: NVRAM support

On Fri, 10 Feb 2006, Bill Davidsen wrote: > Erik Mouw wrote: > > > You could use it for an external journal, or you could use it as a swap > > device. > > > > Let me concur, I used external journal on SSD a decade ago with jfs (AIX). If > you do a lot of operations which generate journal entri

Re: Raid5 & Debian Yaird Woes

On Sun, 5 Feb 2006, Lewis Shobbrook wrote: > On Saturday 04 February 2006 11:22 am, you wrote: > > On Sat, 4 Feb 2006, Lewis Shobbrook wrote: > > > Is there any way to avoid this requirement for input, so that the system > > > skips the missing drive as the raid/initrd system did previously? > > >

Bug#339400: tail -f and append-only files

fyi -- linus has accepted a patch into 2.6.16 which fixes the kernel's behaviour in this case. the kernel was requiring O_APPEND in F_SETFL on append-only files even if the file was opened for read-only... now it requires that the F_SETFL isn't trying to change the O_APPEND flag on an append-on

Re: Raid5 & Debian Yaird Woes

On Sat, 4 Feb 2006, Lewis Shobbrook wrote: > Is there any way to avoid this requirement for input, so that the system > skips > the missing drive as the raid/initrd system did previously? what boot errors are you getting before it drops you to the root password prompt? is it trying to fsck

Bug#351185: use ifrename -t

Package: ifrename Version: 27+28pre13-1 i think /etc/init.d/ifrename should use the -t option... which allows devices to take over already assigned device names... i just had an unstable box which was working ok with an /etc/iftab that explicitly specified eth0/eth1 mac addresses. then i upgra

Re: Raid5 & Debian Yaird Woes

On Thu, 2 Feb 2006, dean gaudet wrote: > i've never looked at yaird in detail -- but you can probably use > initramfs-tools instead of yaird... i take it all back... i just tried initramfs-tools and it failed to boot my system properly... whereas yaird almost got everything right

Bug#351183: use "mdadm -Ac partitions --uuid FOO" to assemble root raid

Package: yaird Version: 0.0.12-3 it's generally preferable to tell mdadm to scan the partitions list to find raid component devices by UUID rather than specify the device list explicitly... for example with an explicit device list you can end up with boot failures if one of the devices is miss

Re: Raid5 & Debian Yaird Woes

i've never looked at yaird in detail -- but you can probably use initramfs-tools instead of yaird... the deb 2.6.14 and later kernels will use whichever one of those is installed. i know that initramfs-tools uses mdrun to start the root partition based on its UUID -- and so it should work fine

Re: Configuring combination of RAID-1 RAID-5

On Tue, 31 Jan 2006, Enrique Garcia Briones wrote: > I have read the setting-up for the raid-5 and 1, but I would like to ask you > if I can set-up a combined RAID configuration as mentioned above, since all > the examples I found upto now just talk of one RAD configuration you can have more th

Re: [rdiff-backup-users] Re: BUG: restore.MirrorStruct.get_increment_times not in 1.0.4's Security.set_allowed_requests()

On Thu, 26 Jan 2006, Charles Duffy wrote: > (Lacking this patch, btw, I was receiving security violations on the specified > method doing a simple restore of a backup specified with "--restore-as-of > 0B"). thanks... patch committed to 1.0.x and 1.1.x branches. -dean _

Re: [rdiff-backup-users] rdiff-backup reliability ad lzop compression

On Fri, 27 Jan 2006, roland wrote: > some "real world" experiences? ('.i´m backing up 2 TB daily and > never had a problem.') it's not 2 TB by any means... but these are the average daily stats for /home backup on my shell server. --[ Average of 32 stat files ]-

Re: [rdiff-backup-users] Re: How to back up SELinux contexts?

On Fri, 27 Jan 2006, dean gaudet wrote: > On Fri, 27 Jan 2006, Troels Arvin wrote: > > > On Thu, 26 Jan 2006 16:48:42 -0800, dean gaudet wrote: > > > > > you probably need to install pyxattr package... i don't know the redhat > > > package n

Re: [rdiff-backup-users] Re: How to back up SELinux contexts?

On Fri, 27 Jan 2006, Troels Arvin wrote: > On Thu, 26 Jan 2006 16:48:42 -0800, dean gaudet wrote: > > > you probably need to install pyxattr package... i don't know the redhat > > package name. install pylibacl while you're at it... > > I already have the

Re: [rdiff-backup-users] How to back up SELinux contexts?

On Wed, 25 Jan 2006, Troels Arvin wrote: > I'm backing up a Red Hat Enterprise Linux 4 with enabled SELinux support. > It seems that SELinux "security contexts" for files aren't backed up by > rdiff-backup. > > I tought that SELinux's security contexts were implemented by extended > attributes (a

Bug#349567: tail -f broken on append-only files

Package: coreutils Version: 5.93-5 bug#339400 was closed prematurely... > > notice that tail -f works fine when the file is not marked append only... > > now don't ask me why O_NONBLOCK is denied on append only files... but it > > is... > > I take it that there is no bug in the tail program, th

Re: [rdiff-backup-users] backup error due to different versions of rdiff-backup

On Sun, 22 Jan 2006, sim wrote: > Dean's package seems to depend on a newer libc6, this is what I got on > a sarge machine: > > puddle:~# dpkg -i rdiff-backup_1.0.4-0.cvs20060120_i386.deb > Selecting previously deselected package rdiff-backup. > (Reading database ... 25685 files and directories c

Re: [Fwd: Re: [rdiff-backup-users] backup error due to different versions of rdiff-backup]

On Fri, 20 Jan 2006, Brian C wrote: > Another option would be to uninstall rdiff-backup from both systems and > then just download 1.0.4 from the website and compile it on both > systems. The installation is extremely simple, but you can't use the > Debian version of librsync. So, as root do this

Re: [rdiff-backup-users] backup error due to different versions of rdiff-backup

On Fri, 20 Jan 2006, Dr. Scott S. Jones wrote: > How do I get both to be the same versions? I run Debian 3.1 on both machines > and keep things updated with apt-get update/upgrade. i'm guessing one of your boxes is stable and the other unstable... unstable has 1.1.5 in it now... and the stable

Re: [rdiff-backup-users] Feature suggestion: Ability to keep a certain number of snapshots

On Wed, 18 Jan 2006, sim wrote: > > On Wed, 18 Jan 2006, Peter Schuller wrote: > > Often I would find it very useful to be able to say "keep the N newest > > snapshots and remove the rest", which is safer. > > Peter, > This feature already exists in rdiff-backup. From the 'Time Formats' > section

Re: [rdiff-backup-users] Backing up the backup server [SOLVED]

On Thu, 19 Jan 2006, Brian C wrote: > Thanks Keith! > > Keith Edmunds wrote: > [snip] > > - if all else fails, set 'LogLevel' to 'DEBUG' in /etc/ssh/sshd_config, > > restart the sshd daemon and post the results of a failed login from > > /var/log/auth (or maybe 'syslog', depending on your setup).

Re: [PATCH 000 of 5] md: Introduction

On Thu, 19 Jan 2006, PFC wrote: > This isn't really a md issue, but it's really annoying only when using > RAID, because it makes a normal process (kicking a dead drive out) so slow > it's almost non-functional. Is there a way to modify the timeout in question ? yeah i posted to l-k about s

Bug#339400: acknowledged by developer (Not a bug)

> > notice that tail -f works fine when the file is not marked append only... > > now don't ask me why O_NONBLOCK is denied on append only files... but it > > is... > > I take it that there is no bug in the tail program, then. there is absolutely a bug in the tail program... this was not a probl

Re: [rdiff-backup-users] Feature suggestion: Ability to keep a certain number of snapshots

On Wed, 18 Jan 2006, Peter Schuller wrote: > I am always reluctant to use --remove-older-than in scripts because > there is always the possibility that the clock is screwed up for > whatever reason and it decides to remove all reverse diffs. Often I > would find it very useful to be able to say "k

Re: Updating superblock to reflect new disc locations

On Thu, 12 Jan 2006, Neil Brown wrote: > On Wednesday January 11, [EMAIL PROTECTED] wrote: > > > > > > Any suggestions would be greatly appreciated. The system's new and not > > yet in production, so I can reinstall it if I have to, but I'd prefer to > > be able to fix something as simple as t

Bug#339400: Info received (was Bug#339400: Acknowledgement (tail -f broken on 2.4 kernel))

aha! i figured out what's going on... it's not a 2.4 vs. 2.6 kernel difference... the difference is that on one of my hosts all of my log files have the "append only" attribute. check this out: /tmp# dpkg -s coreutils ... Version: 5.93-5 /tmp# touch append_only /tmp# tail -f append_only /tmp#

Bug#339400: Acknowledgement (tail -f broken on 2.4 kernel)

hey so i've upgraded to a locally built 2.6.14.4 ... and tail -f is still broken with that kernel. i'm wondering now what's different between debian 2.6.x kernels and my locally built one (it's on a production server though so i can't experiment too much). anyhow i'm really surprised nobody el

Re: [rdiff-backup-users] The rdiff-backup poll!

On Wed, 21 Dec 2005, Ben Escoto wrote: > Unfortunately it uses way too much memory now---1GB to make this > output. It does hold the entire tree in memory, but 1k per file is > more than I expected. it looks like you're keeping data about every file in memory... i hacked around that in mine by

Re: [rdiff-backup-users] The rdiff-backup poll!

On Tue, 20 Dec 2005, Ben Escoto wrote: > >>>>> dean gaudet <[EMAIL PROTECTED]> > >>>>> wrote the following on Tue, 20 Dec 2005 14:06:16 -0800 (PST) > > > > i have to exclude a ~2M inode subtree on my server because its inode > > churn

Re: [rdiff-backup-users] The rdiff-backup poll!

On Wed, 21 Dec 2005, Chris Wilson wrote: > Hi Ben, > > > I actually consider this a feature. Since rdiff-backup only makes one > > pass, it saves time making an extra pass through the directory tree. > > Also, it doesn't need to fit the entire directory list in memory at > > the same time (this

Re: [rdiff-backup-users] The rdiff-backup poll!

On Tue, 20 Dec 2005, Chris Wilson wrote: > The main issue with supporting Rdiff-backup is the interface to Python (from > C++). I was wondering if I could/should embed a Python interpreter in my code > and use that to call rdiff-backup's functions? I would probably also need to > implement callbac

Re: [rdiff-backup-users] The rdiff-backup poll!

On Tue, 20 Dec 2005, Ben Escoto wrote: > > Ben Escoto <[EMAIL PROTECTED]> > > wrote the following on Tue, 20 Dec 2005 13:54:59 -0600 > > > > What do you think about adding this to the rdiff-backup distribution? > > It might be nice to rewrite it in python, and maybe add some bloat. > > >

Re: [rdiff-backup-users] The rdiff-backup poll!

On Tue, 20 Dec 2005, Ben Escoto wrote: > >>>>> dean gaudet <[EMAIL PROTECTED]> > >>>>> wrote the following on Tue, 20 Dec 2005 00:08:26 -0800 (PST) > > > > try <http://arctic.org/~dean/rdiff-backup/backup-statistics> > > ... gi

Re: [rdiff-backup-users] The rdiff-backup poll!

On Mon, 19 Dec 2005, Blair Zajac wrote: > The one feature I think would be handy would be reporting of what was added or > deleted that caused a huge backup. My normal nightly backups are around 20 > Mbytes, but last night I got one that was 220 Mbytes and I'd like to figure > out what changed th

[patch] SFQ "noports" and "nosrcip" support and hash revamp

his patch included upstream so i can eliminate a patch from several of my kernels. thanks -dean p.s. sorry for the attachments, but there's two packages being patched here... Signed-off-by: dean gaudet <[EMAIL PROTECTED]>diff -pru -X linux-2.6.14.4/Documentation/dontdiff linux-2.6.

Re: Journal-guided Resynchronization for Software RAID

On Mon, 5 Dec 2005, Neil Brown wrote: > One of these with built in xor and raid6 would be nice, but I'm not > sure I could guarantee a big enough market for them to try convincing > them to make one... i wonder if the areca cards are re-programmable... they seem to hav

Re: Journal-guided Resynchronization for Software RAID

On Thu, 1 Dec 2005, Neil Brown wrote: > What I would really like is a cheap (Well, not too expensive) board > that had at least 100Meg of NVRAM which was addressable on the PCI > buss, and an XOR and RAID-6 engine connected to the DMA engine. there's the mythical giga-byte i-ram ... i say mythica

Bug#339400: Acknowledgement (tail -f broken on 2.4 kernel)

ugh this whole "blocking optimization" stuff in tail_forever just seems broken... i'm not sure the correct fix, but the following fix seems to do the job for me. i've tested doing tail -f and -F on one and multiple files on 2.6 and 2.4 ... i've done other nonsense tests like "tail -f" on stdin,

Bug#339400: tail -f broken on 2.4 kernel

Package: coreutils Version: 5.93-2 you can't use O_NONBLOCK on files in 2.4... and so tail -f is broken because it apparently requires that now as of 5.93: tail: /var/log/apache/access_log: cannot change nonblocking mode: Operation not permitted i don't think that should be a fatal error (or e

Re: [rdiff-backup-users] Proposal to fix long filenames

On Sun, 13 Nov 2005, Ben Escoto wrote: > > Sheldon Hearn <[EMAIL PROTECTED]> > > wrote the following on Sat, 12 Nov 2005 12:02:45 +0200 > > At the extreme, every object gets a serial number which is used as > > its name in the backup store's filesystem. ... > But this is basically the way

Re: Still Need Help on mdadm and udev

On Thu, 10 Nov 2005, Bill Davidsen wrote: > I haven't had a good use for a partitionable device i've used it to have root, swap, and some external xfs/ext3 logs on a single raid1... (the xfs/ext3 logs are for filesystems on another raid5) rather than managing 4 or 5 separate raid1s on the same

Bug#338200: root raid should use mdadm --config=partitions

Package: initrd-tools Version: 0.1.84 currently for a root on md raid mkinitrd does something like this: mdadm -A /dev/md3 -R -u 2b3a5b77:c7b4ab81:a2b8322a:db5c4e88 /dev/sdb4 /dev/sda4 however this has the problem that it will require the root raid devices to always reside at /dev/sda4 and /dev

Bug#338200: root raid should use mdadm --config=partitions

Package: initrd-tools Version: 0.1.84 currently for a root on md raid mkinitrd does something like this: mdadm -A /dev/md3 -R -u 2b3a5b77:c7b4ab81:a2b8322a:db5c4e88 /dev/sdb4 /dev/sda4 however this has the problem that it will require the root raid devices to always reside at /dev/sda4 and /dev

Re: [rdiff-backup-users] 1.1.2: error with -v 9

On Sun, 6 Nov 2005, Blair Zajac wrote: > File "/sw/lib/python2.4/site-packages/rdiff_backup/log.py", line 135, in > log_to_term > termfp.write(self.format(message, self.term_verbosity)) > IOError: [Errno 35] Resource temporarily unavailable you know there's no reason i can think of we would

Re: [rdiff-backup-users] Fwd: Anacron job 'rdiff-backup.weekly'

On Mon, 7 Nov 2005, Murali Vadivelu wrote: > Another error!! > > > ListError private/var/launchd/0/sock [Errno 1] Operation not permitted: > > '/private/var/launchd/0/sock' maybe try with --exclude-sockets? -dean ___ rdiff-backup-users mailing list

Re: [rdiff-backup-users] Not so serious error/ warning?

On Sun, 6 Nov 2005, Murali Vadivelu wrote: > Is this something to worry about to is it OK? Thanks. > > Begin forwarded message: > > > > Warning: Extended attributes file not found > > UpdateError usernameusername/Library/Application > > Support/SyncServices/Local/clientdata/0063006f006d002e00610

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