[Dirvish] Weird IO problems - and does running the wrong apps in
the wrong terminal emulators crash OSX?
haug at berndhaug.net
Tue Oct 31 16:15:17 PST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Sorry for keeping the traffic on the list abnormally high, but this
is really bugging me:
It's getting weirder by the minute - I noticed that my panics
started showing up when I started dirvish in a shell in a terminal
instead of in an xterm. So I once again started it in an xterm, and
voila, no panics.
Can that really happen? I didn't do anything else differently
between the runs, as far as I'm aware of.
How does using a different terminal emulation panic a system with
"bad dir" errors?
Before the run, BTW, I checked the UFS (fsck /dev/rdisk2s3).
Now, there are no panics any more, but that does not mean everything
[3|1]bhaug at pocketrocket:~$ sudo dirvish --vault home
dirvish home:default error (23) -- partial transfer
dirvish error: branch /Volumes/Backups_A/dirvish_bank/home:default
image 2006-11-01 failed
[3|2]bhaug at pocketrocket:~$ echo $?
[3|3]bhaug at pocketrocket:~$
Quoting from the Docs:
Rsync encountered a non-fatal error.
Which is funny, because /usr/local/bin/dirvish itself includes
22 => [ 'error', "error allocating core memory
23 => [ 'error', "partial transfer" ],
30 => [ 'error', "timeout in data send/receive" ],
125 => [ 'error', "remote shell killed" ],
'error' seems to be a different category than fatal, but "error
allocating core memory", "remote shell killed" or "timeout in data
send/receive" seem pretty fatal to me, as far as it means that the
backup set is hosed.
The log includes multiple lines of:
IO error encountered - skipping file deletion
The rsync_errors includes 5 sections like this:
*** Execution cycle 4 ***
boinc.pbproj): Input/output error (5)
[..more I/O errors that look the same, just different files..]
rsync error: some files could not be transferred (code 23) at
The whole difference between each of the five sections is that the
number in the header line goes from 0 to 4.
I checked the mentioned files, and they all seem to be directories,
but an ls -la in them shows literally nothing (no . and ..), but
rmdir'ing or even rm -rf'ing them results in a "directory not
empty". Suppose those are just broken, why doesn't fsck complain?
Logs and errors also don't get gzipped, and permissions on the
backup directory and the tree don't get relaxed afterwards,
indicating an incomplete run.
/How/ bad is this exactly, practically? Does it mean my backups are
worthless? Is a file-system corrupted? If so, source or target?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Dirvish