So I turned deduplication on on my staging FS (the one that gets mounted on
the database servers) yesterday, and since then I've been seeing the mount
hang for short periods of time off and on. (It lights nagios up like a
Christmas tree 'cause the disk checks hang and timeout.)
I haven't turned dedup off again yet, because I'd like to figure out how to
get past this problem.
Can anyone give me an idea of why the mounts might be hanging, or where to
look for clues? And has anyone had this problem with dedup and NFS before?
FWIW, the clients are a mix of Solaris and Linux.
Paul
Yesterday, Paul Archer wrote:
Yesterday, Arne Jansen wrote:
Paul Archer wrote:
Because it's easier to change what I'm doing than what my DBA does, I
decided that I would put rsync back in place, but locally. So I changed
things so that the backups go to a staging FS, and then are rsync'ed
over to another FS that I take snapshots on. The only problem is that
the snapshots are still in the 500GB range.
So, I need to figure out why these snapshots are taking so much more
room than they were before.
This, BTW, is the rsync command I'm using (and essentially the same
command I was using when I was rsync'ing from the NetApp):
rsync -aPH --inplace --delete /staging/oracle_backup/
/backups/oracle_backup/
Try adding --no-whole-file to rsync. rsync disables block-by-block
comparison if used locally by default.
Thanks for the tip. I didn't realize rsync had that behavior. It looks like
that got my snapshots back to the 50GB range. I'm going to try dedup on the
staging FS as well, so I can do a side-by-side of which gives me the better
space savings.
Paul
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
