Re: [zfs-discuss] ZFS no longer working with FC devices.
I had a similar problem with a RAID shelf (switched to JBOD mode, with each physical disk presented as a LUN) connected via FC (qlc driver, but no MPIO). Running a scrub would eventually generate I/O errors and many messages like this: Sep 6 15:12:53 imsfs scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci10de,5...@e/pci1077,1...@0/f...@0,0/d...@w2100 0004d960cdec,e (sd4): Sep 6 15:12:53 imsfs Request Sense couldn't get sense data and eventually one or more disks would get marked as faulted by ZFS. This was under s10u6 (10/08, I think) but I imagine it still holds for u8. I did not have these problems with just one or two LUNs presented from the array, but I prefer to run ZFS in the recommended configuration where it manages the disks. My storage vendor (3rd-party, not Sun) recommended that in /etc/system I add 'set ssd:ssd_max_throttle = 23' or less and 'set ssd:ssd_io_time = 0x60' or 0x78. The default 0x20 (in what version of Solaris?) is apparently not enough in many cases. In my case (x64) I discovered I needed sd:sd_max_throttle, etc. (not ssd, which is apparently only for sparc), and that the default sd_io_time on recent Solaris 10 already is 0x60. Apparently the general rule for max_throttle is 256/# of LUNs, but my vendor found that 23 was the maximum reliable setting for 16 LUNs. This may or may not help you but it's something to try. Without the max_throttle setting, I would get errors somewhere between 30 minutes and 4 hours into a scrub, and with it scrubs run successfully. -Andrew >>> Demian Phillips 5/23/2010 8:01 AM >>> On Sat, May 22, 2010 at 11:33 AM, Bob Friesenhahn wrote: > On Fri, 21 May 2010, Demian Phillips wrote: > >> For years I have been running a zpool using a Fibre Channel array with >> no problems. I would scrub every so often and dump huge amounts of >> data (tens or hundreds of GB) around and it never had a problem >> outside of one confirmed (by the array) disk failure. >> >> I upgraded to sol10x86 05/09 last year and since then I have >> discovered any sufficiently high I/O from ZFS starts causing timeouts >> and off-lining disks. This leads to failure (once rebooted and cleaned >> all is well) long term because you can no longer scrub reliably. > > The problem could be with the device driver, your FC card, or the array > itself. In my case, issues I thought were to blame on my motherboard or > Solaris were due to a defective FC card and replacing the card resolved the > problem. > > If the problem is that your storage array is becoming overloaded with > requests, then try adding this to your /etc/system file: > > * Set device I/O maximum concurrency > * > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Device_I.2FO_Queue_Size_.28I.2FO_Concurrency.29 > set zfs:zfs_vdev_max_pending = 5 > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > I've gone back to Solaris 10 11/06. It's working fine, but I notice some differences in performance that are I think key to the problem. With the latest Solaris 10 (u8) throughput according to zpool iostat was hitting about 115MB/sec sometimes a little higher. With 11/06 it maxes out at 40MB/sec. Both setups are using mpio devices as far as I can tell. Next is to go back to u8 and see if the tuning you suggested will help. It really looks to me that the OS is asking too much of the FC chain I have. The really puzzling thing is I just got told about a brand new Dell Solaris x86 production box using current and supported FC devices and a supported SAN get the same kind of problems when a scrub is run. I'm going to investigate that and see if we can get a fix from Oracle as that does have a support contract. It may shed some light on the issue I am seeing on the older hardware. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] How to clear invisible, partially received snapshots?
I currently use zfs send/recv for onsite backups [1], and am configuring it for replication to an offsite server as well. I did an initial full send, and then a series of incrementals to bring the offsite pool up to date. During one of these transfers, the offsite server hung, and I had to power-cycle it. It came back up just fine, except that the snapshot it was receiving when it hung appeared to be both present and nonexistent, depending on which command was run. 'zfs recv' complained that the target snapshot already existed, but it did not show up in the output of 'zfs list', and 'zfs destroy' said it did not exist. I ran a scrub, which did not find any errors; nor did it solve the problem. I discovered some useful commands with zdb [2], and found more info: zdb -d showed the snapshot, with an unusual name: Dataset backup/ims/%zfs-auto-snap_daily-2010-04-22-1900 [ZPL], ID 6325, cr_txg 28137403, 2.62T, 123234 objects As opposed to a normal snapshot: Dataset backup/i...@zfs-auto-snap_daily-2010-04-21-1900 [ZPL], ID 5132, cr_txg 27472350, 2.61T, 123200 objects I then attempted 'zfs destroy backup/ims/%zfs-auto-snap_daily-2010-04-22-1900', but it still said the dataset did not exist. Finally I exported the pool, and after importing it, the snapshot was gone, and I could receive the snapshot normally. Is there a way to clear a "partial" snapshot without an export/import cycle? Thanks, Andrew [1] http://mail.opensolaris.org/pipermail/zfs-discuss/2009-December/034554.html [2] http://www.cuddletech.com/blog/pivot/entry.php?id=980 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On Tue, 2010-03-09 at 20:47 -0800, mingli wrote: > And I update the sharenfs option with "rw,ro...@100.198.100.0/24", it works > fine, and the NFS client can do the write without error. > > Thanks. I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). Perhaps it's because I left the NFSv4 domain setting at the default. (I'm just using NFSv3, but trying to come up with an explanation. In any case, using the FQDN works.) -Andrew ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to get a list of changed files between twosnapshots?
>>> Richard Elling 2/3/2010 6:06 PM >>> On Feb 3, 2010, at 3:46 PM, Ross Walker wrote: > On Feb 3, 2010, at 12:35 PM, Frank Cusack > wrote: > > So was there a final consensus on the best way to find the difference between > two snapshots (files/directories added, files/directories deleted and > file/directories changed)? > > Find won't do it, ddiff won't do it, I think the only real option is rsync. > Of course you can zfs send the snap to another system and do the rsync there > against a local previous version. bart(1m) is designed to do this. -- richard Unless something has changed in the past couple months, bart(1m) does not work on large filesystems (2TB limit, I think). http://opensolaris.org/jive/message.jspa?messageID=433896#433896 My solution to this was rsync in dry-run mode between two snapshot directories, which runs in a few seconds and lists both added/changed files and deleted files. http://opensolaris.org/jive/message.jspa?messageID=434176#434176 -Andrew ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] my ZFS backup script -- feedback appreciated
After successfully setting up the ZFS auto snapshot package, I was at the point of implementing its backup functionality when I saw the announcement of the removal of that, and the associated uproar. I looked deeper and discovered that the autosnap backup didn't really meet my needs after all, and couldn't find anything else out there that did, so I wrote my own script using the zfs send/receive functionality to replicate snapshots to another host. It works as intended, but I'm sure it could be improved. Something I know would be a good change would be converting it to an SMF service, and replacing the lockfile bit with SMF maintenance state, but I don't know SMF manifests that well, so hopefully someone can contribute one! I also know the error handling could be abstracted out and improved somewhat. I check for the failure cases I can think of and drop to maintenance in case any of those happen. Description/rationale of the script (more detailed comments within the script): # This supplements zfs-auto-snapshot, but runs independently. I prefer that # snapshots continue to be taken even if the backup fails. # # This aims to be much more robust than the backup functionality of # zfs-auto-snapshot, namely: # * it uses 'zfs send -I' to send all intermediate snapshots (including # any daily/weekly/etc.), and should still work even if it isn't run # every hour -- as long as the newest remote snapshot hasn't been # rotated out locally yet # * 'zfs recv -dF' on the destination host removes any snapshots not # present locally so you don't have to worry about manually removing # old snapshots there. I realize this doesn't meet everybody's needs but hopefully someone will find it useful. Note: I'm running sol10u8. I expect this to work fine on recent OpenSolaris also, but I have not tested that. The only change required to make zfs-auto-snapshot v0.12 work on sol10u8 was changing ksh93 to dtksh in the shebang line. Andrew Daugherity Systems Analyst Division of Research & Graduate Studies Texas A&M University zfs-backup.sh Description: Bourne shell script ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs inotify?
Thanks for info, although the audit system seems a lot more complex than what I need. Would still be nice if they fixed bart to work on large filesystems, though. Turns out the solution was right under my nose -- rsync in dry-run mode works quite well as a "snapshot diff" tool. I'll share this with the list, in case it helps anyone else. For example: rsync -avn --delete-before /export/ims/.zfs/snapshot/zfs-auto-snap_daily-2009-11-09-1900/ /export/ims/.zfs/snapshot/zfs-auto-snap_daily-2009-11-08-1900/ This makes a list of what files have been changed, added, or deleted between these two snapshots, and runs in about 10 seconds. If you cared to see changes within files (I don't), it would be trivial to add a loop along the lines of '$rsync_cmd | while read file; do diff $snap1/$file $snap2/file; done'. Note the trailing slashes (otherwise rsync works one directory higher and considers the snapshot directory name, which we don't want) and that the newer snapshot is the "source" and the older snapshot, the destination. I'm [ab]using rsync to have it tell me exactly how it would make the "destination" be a replica of the "source". FWIW, I'm using rsync 3.0.6 from opencsw. Older rsync should work fine but may take longer to run. -Andrew >>> Richard Elling 11/9/2009 7:33 PM >>> Seems to me that you really want auditing. You can configure the audit system to only record the events you are interested in. http://docs.sun.com/app/docs/doc/816-4557/auditov-1?l=en&a=view -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs inotify?
>>> Robert Thurlow 11/9/2009 4:25 PM >>>
% file /bin/truss /bin/amd64/truss
/bin/truss: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
/bin/amd64/truss: ELF 64-bit LSB executable AMD64 Version 1 [SSE2
SSE FXSR CMOV FPU], dynamically linked, not stripped, no debugging
information available
It doesn't make any difference if I invoke it with the amd64 truss. The only
bart binary I can find on the system (Sol 10u8) is /usr/bin/bart, and it
definitely calls statvfs(). Truss log follows at the end.
I know all about 'find -mtime ...', but that doesn't show which files have been
deleted, whereas 'rsync -av --delete --backup-dir=`date +%Y%m%d`' does. (When
users delete files and then need them restored a week later, it's very helpful
to know which day they were deleted, as I can avoid running a find that could
take quite a while. I think incremental zfs snapshots are a better strategy
but there are little hurdles like this to be crossed.)
bart (or something faster than running 'gdiff -qr snap1 snap2' on a snapshots
of a 2.1TB-and-growing FS) seems like a great idea, if I could find a working
tool. It looks like dircmp(1) might be a possibility, but I'm open to
suggestions. I suppose I could use something like AIDE or tripwire, although
that seems a bit like swatting a fly with a sledgehammer.
Thanks,
Andrew
and...@imsfs-new:~$ /usr/bin/amd64/truss bart create -R /export/ims >
/tmp/bart-ims
execve("/usr/bin/bart", 0x08047D6C, 0x08047D80) argc = 4
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFEFF
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
resolvepath("/usr/bin/bart", "/usr/bin/bart", 1023) = 13
sysconfig(_CONFIG_PAGESIZE) = 4096
stat64("/usr/bin/bart", 0x08047B00) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libsec.so.1", 0x080473A0) = 0
resolvepath("/lib/libsec.so.1", "/lib/libsec.so.1", 1023) = 16
open("/lib/libsec.so.1", O_RDONLY) = 3
mmap(0x0001, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) =
0xFEFB
mmap(0x0001, 143360, PROT_NONE,
MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEF8
mmap(0xFEF8, 50487, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3,
0) = 0xFEF8
mmap(0xFEF9D000, 11909, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 53248) = 0xFEF9D000
mmap(0xFEFA, 8296, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON,
-1, 0) = 0xFEFA
munmap(0xFEF8D000, 65536) = 0
memcntl(0xFEF8, 8844, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(3)= 0
stat64("/lib/libmd.so.1", 0x080473A0) = 0
resolvepath("/lib/libmd.so.1", "/lib/libmd.so.1", 1023) = 15
open("/lib/libmd.so.1", O_RDONLY) = 3
mmap(0xFEFB, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFEFB
mmap(0x0001, 126976, PROT_NONE,
MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEF6
mmap(0xFEF6, 56424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3,
0) = 0xFEF6
mmap(0xFEF7E000, 552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA,
3, 57344) = 0xFEF7E000
munmap(0xFEF6E000, 65536) = 0
memcntl(0xFEF6, 1464, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(3)= 0
stat64("/lib/libc.so.1", 0x080473A0)= 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)= 3
mmap(0xFEFB, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFEFB
mmap(0x0001, 1208320, PROT_NONE,
MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE3
mmap(0xFEE3, 1099077, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT,
3, 0) = 0xFEE3
mmap(0xFEF4D000, 30183, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 1101824) = 0xFEF4D000
mmap(0xFEF55000, 4240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON,
-1, 0) = 0xFEF55000
munmap(0xFEF3D000, 65536) = 0
memcntl(0xFEE3, 124080, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(3)= 0
stat64("/lib/libavl.so.1", 0x080473A0) = 0
resolvepath("/lib/libavl.so.1", "/lib/libavl.so.1", 1023) = 16
open("/lib/libavl.so.1", O_RDONLY) = 3
mmap(0xFEFB, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFEFB
mmap(0x0001, 73728, PROT_NONE,
MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE1
mmap(0xFEE1, 2788, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3,
0) = 0xFEE1
mmap(0xFEE21000, 204, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA,
3, 4096) = 0xFEE21000
munmap(0xFEE11000, 65536) = 0
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
Re: [zfs-discuss] zfs inotify?
I'd hoped this script would work for me as a "snapshot diff" script, but it
seems that bart doesn't play well with large filesystems (don't know the
cutoff, but my zfs pools (other than rpool) are all well over 4TB).
'bart create' fails immediately with a "Value too large for defined data type"
error, and this is in fact mentioned in the Solaris 10 10/09 release notes:
Possible Error With 32-bit Applications Getting File System State on Large File
Systems (6468905)
When run on large file systems, for example ZFS, applications using statvfs(2)
or statfs(2) to get information about the state of the file system exhibit an
error. The following error message is displayed:
Value too large for defined data type
Workaround: Applications should use statvfs64() instead.
from
http://docs.sun.com/app/docs/doc/821-0381/gdzmr?l=en&a=view
and in fact, if I invoke bart via truss, I see it calls statvfs() and fails.
Way to keep up with the times, Sun!
Is there a 64-bit version of bart, or a better recommendation for comparing
snapshots? My current backup strategy uses rsync, which I'd like to replace
with zfs send/receive, but I need a way to see what changed in the past day.
Thanks,
Andrew Daugherity
Systems Analyst
Division of Research & Graduate Studies
Texas A&M University
>>> Trevor Pretty 10/26/2009 5:16 PM >>>
Paul
Being a script hacker like you the only kludge I can think of.
A script that does something like
ls > /tmp/foo
sleep
ls /tmp/foo.new
diff /tmp/foo /tmp/foo.new >/tmp/files_that_have_changed
mv /tmp/foo.new /tmp/foo
Or you might be able to knock something up with bart nd zfs snapshots. I did
write this which may help?
#!/bin/sh
#set -x
# Note: No implied warranty etc. applies.
# Don't cry if it does not work. I'm an SE not a programmer!
#
###
#
# Version 29th Jan. 2009
#
# GOAL: Show what files have changed between snapshots
#
# But of course it could be any two directories!!
#
###
#
## Set some variables
#
SCRIPT_NAME=$0
FILESYSTEM=$1
SNAPSHOT=$2
FILESYSTEM_BART_FILE=/tmp/filesystem.$$
SNAPSHOT_BART_FILE=/tmp/snapshot.$$
CHANGED_FILES=/tmp/changes.$$
## Declare some commands (just in case PATH is wrong, like cron)
#
BART=/bin/bart
## Usage
#
Usage()
{
echo ""
echo ""
echo "Usage: $SCRIPT_NAME -q filesystem snapshot "
echo ""
echo " -q will stop all echos and just list the changes"
echo ""
echo "Examples"
echo "$SCRIPT_NAME /home/fred/home/.zfs/snapshot/fred "
echo "$SCRIPT_NAME . /home/.zfs/snapshot/fred "
echo ""
echo ""
exit 1
}
### Main Part ###
## Check Usage
#
if [ $# -ne 2 ]; then
Usage
fi
## Check we have different directories
#
if [ "$1" = "$2" ]; then
Usage
fi
## Handle dot
#
if [ "$FILESYSTEM" = "." ]; then
cd $FILESYSTEM ; FILESYSTEM=`pwd`
fi
if [ "$SNAPSHOT" = "." ]; then
cd $SNAPSHOT ; SNAPSHOT=`pwd`
fi
## Check the filesystems exists It should be a directory
# and it should have some files
#
for FS in "$FILESYSTEM" "$SNAPSHOT"
do
if [ ! -d "$FS" ]; then
echo ""
echo "ERROR file system $FS does not exist"
echo ""
exit 1
fi
if [ X"`/bin/ls "$FS"`" = "X" ]; then
echo ""
echo "ERROR file system $FS seems to be empty"
exit 1
echo ""
fi
done
## Create the bart files
#
echo ""
echo "Creating bart file for $FILESYSTEM can take a while.."
cd "$FILESYSTEM" ; $BART create -R . > $FILESYSTEM_BART_FILE
echo ""
echo "Creating bart file for $SNAPSHOT can take a while.."
cd "$SNAPSHOT" ; $BART create -R . > $SNAPSHOT_BART_FILE
## Compare them and report the diff
#
echo ""
echo "Changes"
echo ""
$BART compare -p $FILESYSTEM_BART_FILE $SNAPSHOT_BART_FILE | awk '{print $1}' >
$CHANGED_FILES
/bin/more $CHANGED_FILES
echo ""
echo ""
echo ""
## Tidy kiwi
#
/bin/rm $FILESYSTEM_BART_FILE
/bin/rm $SNAPSHOT_BART_FILE
/bin/rm $CHANGED_FILES
exit 0
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] possible to override/inherit mountpoint on received snapshots?
I attempted to migrate data from one zfs pool to another, larger one (both
pools are currently mounted on the same host) using the snapshot send/receive
functionality. Of course, I could use something like rsync/cpio/tar instead,
but I'd have to first manually create all the target FSes, and send/receive
seemed like a better option.
Unfortunately, this trips up on filesystems that have mountpoints explicitly
set, as after receiving the snapshot, it attempts to mount the target FS at the
same mountpoint as the source FS, which obviously fails. The "zfs receive"
command aborts here and doesn't try to receive any other FSes.
The source pool:
and...@imsfs-mirror:~$ zfs list -t filesystem -r ims_pool_mirror
NAME USED AVAIL REFER MOUNTPOINT
ims_pool_mirror 3.78T 498G 46.0K /ims_pool_mirror
ims_pool_mirror/backup 1.99T 498G 749M /export/backup
ims_pool_mirror/backup/bushlibrary 54.7G 498G 54.7G
/export/backup/bushlibrary
ims_pool_mirror/backup/bvcnet429M 498G 429M /export/backup/bvcnet
ims_pool_mirror/backup/isc 129G 498G 129G /export/backup/isc
[several more FSes under ims_pool_mirror/backup omitted for brevity]
ims_pool_mirror/ims 1.79T 498G 1.79T /export/ims
ims_pool_mirror/ims/webroot 62.4M 498G 60.3M /export/ims/webroot
I took a recursive snapshot ("@0702") and attempted to copy it to the new pool
(named "ims_mirror_new" for now) and ran into the above problem. I hit the
same issue when dropping down a level to ims_pool_mirror/backup, but not when
going down a level below that (to e.g. ims_pool_mirror/backup/bushlibrary). In
a certain way this make sense, since it's backup that has the mountpoint set,
and the FSes under it just inherit their mountpoints, but it isn't immediately
obvious.
What's more confusing is that doing a dry-run succeeds (for all FSes), but
removing the '-n' flag causes it to fail after the first FS:
r...@imsfs-mirror:/# zfs send -R ims_pool_mirror/bac...@0702 | zfs receive -nv
-F -d ims_mirror_new
would receive full stream of ims_pool_mirror/bac...@0702 into
ims_mirror_new/bac...@0702
would receive full stream of ims_pool_mirror/backup/bvc...@0702 into
ims_mirror_new/backup/bvc...@0702
would receive full stream of ims_pool_mirror/backup/z...@0702 into
ims_mirror_new/backup/z...@0702
would receive full stream of ims_pool_mirror/backup/j...@0702 into
ims_mirror_new/backup/j...@0702
would receive full stream of ims_pool_mirror/backup/z...@0702 into
ims_mirror_new/backup/z...@0702
would receive full stream of ims_pool_mirror/backup/ocfs...@0702 into
ims_mirror_new/backup/ocfs...@0702
would receive full stream of ims_pool_mirror/backup/my...@0702 into
ims_mirror_new/backup/my...@0702
would receive full stream of ims_pool_mirror/backup/i...@0702 into
ims_mirror_new/backup/i...@0702
would receive full stream of ims_pool_mirror/backup/bushlibr...@0702 into
ims_mirror_new/backup/bushlibr...@0702
would receive full stream of ims_pool_mirror/backup/purgat...@0702 into
ims_mirror_new/backup/purgat...@0702
would receive full stream of ims_pool_mirror/backup/l...@0702 into
ims_mirror_new/backup/l...@0702
would receive full stream of ims_pool_mirror/backup/the...@0702 into
ims_mirror_new/backup/the...@0702
would receive full stream of ims_pool_mirror/backup/pg...@0702 into
ims_mirror_new/backup/pg...@0702
r...@imsfs-mirror:/# zfs send -R ims_pool_mirror/bac...@0702 | zfs receive -v
-F -d ims_mirror_new
receiving full stream of ims_pool_mirror/bac...@0702 into
ims_mirror_new/bac...@0702
cannot mount '/export/backup': directory is not empty
Of course it can't, since that mountpoint is used by the source pool!
Doing the child FSes (which inherit) one at a time works just fine:
r...@imsfs-mirror:/# zfs send -R ims_pool_mirror/backup/bvc...@0702 | zfs
receive -v -d ims_mirror_new
receiving full stream of ims_pool_mirror/backup/bvc...@0702 into
ims_mirror_new/backup/bvc...@0702
received 431MB stream in 10 seconds (43.1MB/sec)
Now that I understand the behavior, I have to ask: (1) Where is this
documented? I didn't see anything in the zfs admin guide saying "receiving a
snapshot with a local mountpoint set will attempt to mount it there, and the
receive operation will fail if it can't." I see it stated that the target FS
name must not exist, but the examples use inherited mountpoints (e.g. the
"users2" example on p.202), which I thought I was following, until I realized
the local mountpoint issue was tripping me up.
(2) (More importantly) Is there a workaround to force snapshots received with
"zfs receive -d" to inherit their mountpoint from the pool they are imported
into, and/or explicitly override it?
Thanks,
Andrew Daugherity
Systems Analyst
Divis
