On Sun, 11 Jun 2006, Douglas Bollinger wrote:
On Sat, 10 Jun 2006 13:07:46 -0700 (PDT)
dean gaudet [EMAIL PROTECTED] wrote:
snip
rdiff-backup, for better or worse, does a chmod on the directory while
it's operating. it has no problems with the directory... i even tried
removing
On Wed, 7 Jun 2006, Chris Fanning wrote:
I've got a problem running rdiff-backup as a cron job.
do you get any mail from cron? usually you should get some mail with
stdout/stderr in it... i'm guessing it would help diagnose this...
-dean
___
[i've cc'd the md/mdadm maintainer so he can chime in if i'm making an
error... Neil if you want to see the entire thread it's visible at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351183.]
On Tue, 2 May 2006, Jason Lunz wrote:
I agree. Unfortunately, telling mdadm to scan other
On Tue, 6 Jun 2006, Jonas Smedegaard wrote:
It is wrong to assume a purely no-older-than-etch system: Imagine the
process of upgrading from sarge to etch...
aha... now i understand :)
what you really need is some sort of weak dependency which implies that
if the package is already installed
On Wed, 7 Jun 2006, Jonas Smedegaard wrote:
...
Well, the above puts the test at boot time. That's ugly IMHO.
I'd prefer resolving mdadm features at build time. Something like this:
* Resolve mdadm capabilities in Plan.pm
* Set some variable (not the version, but flags each capability)
On Fri, 2 Jun 2006, Douglas Bollinger wrote:
On Wed, 31 May 2006 07:59:26 -0700 (PDT)
dean gaudet [EMAIL PROTECTED] wrote:
On Mon, 29 May 2006, Douglas Bollinger wrote:
Anyone see this and is there an easy workaround?
this sounds like an older bug... what version are you using
On Mon, 29 May 2006, Douglas Bollinger wrote:
Anyone see this and is there an easy workaround?
this sounds like an older bug... what version are you using?
-dean
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
On Wed, 31 May 2006, Neil Brown wrote:
On Tuesday May 30, [EMAIL PROTECTED] wrote:
actually i think the rate is higher... i'm not sure why, but klogd doesn't
seem to keep up with it:
[EMAIL PROTECTED]:~# grep -c kblockd_schedule_work /var/log/messages
31
[EMAIL PROTECTED]:~#
On Sun, 28 May 2006, Neil Brown wrote:
The following patch adds some more tracing to raid5, and might fix a
subtle bug in ll_rw_blk, though it is an incredible long shot that
this could be affecting raid5 (if it is, I'll have to assume there is
another bug somewhere). It certainly doesn't
On Sun, 28 May 2006, Luca Berra wrote:
- mdadm-2.5-rand.patch
Posix dictates rand() versus bsd random() function, and dietlibc
deprecated random(), so switch to srand()/rand() and make everybody
happy.
fwiw... lots of rand()s tend to suck... and RAND_MAX may not be large
enough for this
On Sun, 28 May 2006, Luca Berra wrote:
dietlibc rand() and random() are the same function.
but random will throw a warning saying it is deprecated.
that's terribly obnoxious... it's never going to be deprecated, there are
only approximately a bazillion programs using random().
-dean
-
To
reopen 211858
tag 211858 patch
thanks
hi... i think there's been some confusion w.r.t. bug#211858. it could be
my fault, or it could just be that the package changed again between 2004
and 2006... anyhow the current state of the sysklogd package is that this
bug exists -- a regular user can
On Tue, 23 May 2006, Neil Brown wrote:
I've spent all morning looking at this and while I cannot see what is
happening I did find a couple of small bugs, so that is good...
I've attached three patches. The first fix two small bugs (I think).
The last adds some extra information to
On Sat, 27 May 2006, Neil Brown wrote:
On Friday May 26, [EMAIL PROTECTED] wrote:
On Tue, 23 May 2006, Neil Brown wrote:
i applied them against 2.6.16.18 and two days later i got my first hang...
below is the stripe_cache foo.
thanks
-dean
neemlark:~# cd /sys/block/md4/md/
On Thu, 25 May 2006, Kannarat Chiemchitvanicha wrote:
However, it seems like I have a problem with the 32-bit/64-bit mismatch and
I need to relink the library in the 64-bit mode.
yes, the .so must match the architecture of the python binary.
-dean
On Thu, 25 May 2006, Niki Hammler wrote:
1.) Is there a way to save old increments to another directory?
nope.
2.) If for example would like to restore a file 365 days. Is it correct that I
have to apply all diffs since then?
yep. one of the commonly requested features is the ability to
On Wed, 24 May 2006, Steve Clement wrote:
dean gaudet wrote:
rdiff-backup --remote-schema '%s' src 'rdiff-backup --server'::dst
Well ssh is not the best file carrier, scp for instance is slow as...
but there is a HPN Patch:
i think you missed my point... remote rdiff-backup is slow even
On Wed, 24 May 2006, Mike Weisenborn wrote:
I have a fairly good-sized (34G) backup set of which 17G or so is the
current data, and another 17G is the last 30 days of incrementals.
I'm trying to create a snapshot of this data in another location by doing
this:
rdiff-backup -r now
On Wed, 24 May 2006, Adam Lazur wrote:
ValueError: invalid literal for long(): 22714811 ModTime 11037487348i55id 1003
that looks fairly well corrupted...
Is it time to perform surgery on the metadata file? I'm cool with
blowing away portions of the tree to save my backup... but I'd rather
On Mon, 22 May 2006, [EMAIL PROTECTED] wrote:
Hi:
--remove-older-than fails at some condition.
example procedure below:
[EMAIL PROTECTED] tmp]# mkdir foo
[EMAIL PROTECTED] tmp]# touch foo/a
[EMAIL PROTECTED] tmp]# rdiff-backup --version
rdiff-backup 1.1.5
[EMAIL PROTECTED] tmp]#
On Tue, 23 May 2006, Steve Clement wrote:
This is over a gigabit link SATA Raid 10 , conclude for yourselves.
i'm guessing you're saying the results are bad...
initial network backup is well known to be slow... in fact it's slow as
soon as you use separate processes, as can be demonstrated
On Sun, 21 May 2006, Randall Nortman wrote:
I'm not sure where to look for this in the metadata.
look in the mirror_metadata file in the rdiff-backup-data subdirectory of
the target... you could probably gunzip and edit away the entry for that
file.
i think this one is fixed by later revs,
rdiff-backup requires a significant amount of extra space to fit its
filenames... at least until 1.1.x where ben has made it able to deal with
File name too long errors more gracefully... however i think based on
the bug reports i've seen here i'd hesitate to use 1.1.x.
-dean
On Sun, 21 May
On Thu, 11 May 2006, dean gaudet wrote:
On Tue, 14 Mar 2006, Neil Brown wrote:
On Monday March 13, [EMAIL PROTECTED] wrote:
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
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
On Mon, 15 May 2006, The Anarcat wrote:
/: write failed, file system is full
...
IOError: [Errno 28] No space left on device
Why the heck does it go write in /? /tmp? Why not use a tmp dir in the
target? And how can it use 130M of tmp?
that first error looks more like some general libc or
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
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
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
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
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
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
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
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 minors 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
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
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
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 start them in the right minor devices. try doing
On Mon, 10 Apr 2006, Marc L. de Bruin wrote:
However, all preferred minors 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 seems to
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 build
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
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 page for
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
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
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 at
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, regressing
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
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
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
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
...
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
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
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
On Mon, 13 Mar 2006, Alex Meaden wrote:
Warning Security Violation!
Bad request for function: fs_abilities.get_fsabilities_readwrite
with arguments: ['destination', rdiff_backup.rpath.RPath instance at
0xb7a1b5ac, 1, None]
i'm pretty sure that's fixed in 1.0.something...
did you add
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
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 read
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 disk (which is ok now but going to
die), so
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 disk will no longer be considered
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 (this
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 same
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=detailaid=1439412group_id=56125atid=479441
and
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 to
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
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;
-
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
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 and
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 device names... i just had an
unstable box
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 entries, file
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?
what boot
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
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
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
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.
the main
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
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
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 than
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
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 name. install pylibacl while you're at it...
I already have
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 python-xattr and python-libacl packages
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 (and that
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, then.
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 on
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 of the man
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
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 problem in
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 this.
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
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#
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
... give it the path to your mirror.
What do you think about adding this to the rdiff-backup
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 is way too high for my dsl + home /backup disk to accomodate.
(it's the http
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 http://www.areca.com.tw/ are
re-programmable... they seem to have
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 mythical
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
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,
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 most backup
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
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
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
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 at
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 get
On Fri, 4 Nov 2005, Fran Firman wrote:
At the moment I find a lot of false positives. ie a file is backed up
when it has not changed at all. When I was first reading about
rdiff-backup, and that it used rsync-lib, it seemed to be a side affect
of the rsync library. It had to do with the
401 - 500 of 1643 matches
Mail list logo
