On Oct 7, 2010, at 11:40 AM, Jim Sloey wrote: > One of us found the following: > > The presence of snapshots can cause some unexpected behavior when you attempt > to free space. Typically, given appropriate permissions, you can remove a > file from a full file system, and this action results in more space becoming > available in the file system. However, if the file to be removed exists in a > snapshot of the file system, then no space is gained from the file deletion. > The blocks used by the file continue to be referenced from the snapshot.
Yes, as designed. > As a result, the file deletion can consume more disk space, because a new > version of the directory needs to be created to reflect the new state of the > namespace. This behavior means that you can get an unexpected ENOSPC or > EDQUOT when attempting to remove a file. Yes, as designed. > Since we are using snapshots to a remote system, what will be the impact of > destroying the snapshots? Since the files we moved are some of the oldest, > will we have to start replication to the remote site over again from the > beginning? In most cases where we implement this, the remote (backup) system will have more snapshots than the production system. All you really need is a single, common snapshot between the two to re-start an incremental send/receive. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com ZFS and performance consulting http://www.RichardElling.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
