Open GoogleCodeExporter opened 9 years ago
What version of rsync were you using?
I seem to recall some versions (older than 3.0 maybe?) of rsync try to read the
whole filesystem tree which
causes the problem you saw, so if possible try building the current (stable)
version of rsync and see if that
eliminates the issue.
I hate the workaround, as this there never should never be a case where a
userland program can cause a
problem like this, but for now, I think it's all we've got.
Original comment by jason.richard.mcneil
on 15 Jan 2010 at 5:34
It doesn't occur every time, has only happened once out of like 100 backups.
macpro:~ sam$ rsync --version
rsync version 3.0.6 protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, file-flags
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
macpro:~ sam$
Original comment by spull...@gmail.com
on 15 Jan 2010 at 5:46
Could you run zoink in another terminal window while doing these rsyncs and
possibly take a photo of the
zoink output if/when it kernel panics? I'm wondering if for some reason it's
keeping around too many large
zio_bufs, as that's the only thing I see right away that is the same size
(131072 bytes).
If a panic isn't easy, or very undesired to cause, a dump of the a single zoink
status window after your pool
has been up for a while might also give me some ideas.
Sorry if it sounds like I'm guessing, but since I don't have anywhere else to
start, that's the best I can do for
now…
Original comment by jason.richard.mcneil
on 16 Jan 2010 at 7:08
I'll try and remember to do that each time I do a backup. I can show you
before, during
and after but it didn't crash this time.
Original comment by spull...@gmail.com
on 16 Jan 2010 at 8:40
Attachments:
I know that RSync uses mmap for its calls; maybe that's implicated in the bug.
In any case, it's certainly true
that the code does have a panic() if the memory can't be allocated; there's a
note in there to call 'kmem_reap'
but that doesn't seem to be called. Ideally we shouldn't panic the system if we
can't allocate memory, but will
need to find out the call paths that can get to that point (and whether we can
figure out a way of returning a
non-panic error code instead).
Original comment by alex.ble...@gmail.com
on 10 Mar 2010 at 8:02
Maybe using 64-bit kernel (from your logs I see that you use 32-bit MacOS
kernel) would help.
Original comment by numise...@gmail.com
on 8 Sep 2010 at 3:04
I was having the same problem, but then I forced my 10.6 server to use the
64bit kernel instead of the 32bit kernel and the problem went away.
Thanks for the suggestion
-- Shaheen Ghiassy
Original comment by s.ghia...@gmail.com
on 16 Sep 2012 at 9:49
Original issue reported on code.google.com by
spull...@gmail.com
on 9 Jan 2010 at 7:12