On August 19, 2006 7:06:06 PM -0700 Matthew Ahrens <[EMAIL PROTECTED]> wrote:
On Sat, Aug 19, 2006 at 06:31:47PM -0700, Frank Cusack wrote:
But when I login to zone smb and cd to /share/tmp/.zfs I get 'no such
file or directory'. This does exist for other filesystems like
/zone/eng/.zfs.
My guess is that the filesystem is not mounted. It should be remounted
after the 'zfs recv', but perhaps that is not happening correctly. You
can see if it's mounted by running 'df' or 'zfs list -o name,mounted'.
You are right, it's not mounted.
Did the 'zfs recv' print any error messages?
nope.
Are you able to reproduce this behavior?
easily.
1. Is the need to reboot a bug? Certainly having the other snapshots
go missing seems like a bug.
Yes, it is a bug for the filesystem to not be remounted after the 'zfs
recv'. FYI, you should be able to get it mounted again by running 'zfs
mount -a', you don't have to reboot the entire zone.
yay, that works.
2. Why does the 7.1 snapshot have the extra space?
If the filesystem (export/zone/smb/share/tmp) is modified, then some of
the data that it shared with the snapshot (@7.1) will not be shared any
longer, so it will become unique to the snapshot and show up as "used"
space. Even if you didn't explicitly change anything in the filesystem,
with the default settings, simply reading files in the filesystem will
cause their atimes to be modified.
ah ok. Note that if I do zfs send; zfs send -i on the "local side", then
do zfs list; zfs mount -a on the "remote side", I still show space used
in the @7.1 snapshot, even though I didn't touch anything. I guess mounting
accesses the mount point and updates the atime.
On the "local" side, how come after I take the 7.1 snapshot and then 'ls',
the 7.1 snapshot doesn't start using up space? Shouldn't my ls of the
mountpoint update the atime also?
-frank
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
