preventing deadlocks in snapshot directories - unexplained

Eric Anderson anderson at
Fri Jan 13 06:39:55 PST 2006

Oliver Fromme wrote:
> user <user at> wrote:
>  > I have asked this before, but nobody answered ...
> Many people tend to be reluctant answering questions
> from anonymous users (or they don't bother reading their
> questions at all).
>  > If you have multiple snapshots, how do you segregate them in order to
>  > avoid the deadlocks that the ".snap" directory is supposed to fix ?
> As far as I know, using that directory is just a matter of
> convention.  You can place snapshots anywhere else, and it
> doesn't make a difference.  The only thing special about
> ".snap" is that it is created by default by newfs(1), and
> it is expected to exist by the snapshot support of the
> dump(8) and fsck(8) tools (for dumping live file systems
> and background fsck, respectively).
>  > I understand why a snapshot is created in (mount)/.snap - but what if I
>  > have multiple snapshots running simultaneously ?
> It doesn't make a difference.
>  > cd /.snap
>  > rm -rf snap3
>  > 
>  > the _entire_ /.snap directory locks up until that command completes.
> Well, yes, certain file system operations are blocked
> until the removal of the snapshot is complete, which
> can take quite some time, depending on the size of the
> file system, because a lot of data has to be updated.
> So, that blocking is to be expected (unfortunately).
>  > So, this leads me to conclude that actually, I need to do this:
>  > 
>  > /.snap/snapshot_file
>  > /.snap2/snapshot_file
>  > /.snap3/snapshot_file
> No, it doesn't make a difference.  As far as I know, the
> snapshot code doesn't care about the directory name where
> the snapshot files are placed.

Well, its ok to put snapshots anywhere, but when operations on a 
snapshot file are in progress, stat calls on the snapshot file will 
block.  I think this is his problem.  I wonder how painful it would be 
to have stat's on snapshot files return with (something) when a snapshot 
operation is in progress, instead of blocking, or even if that is possible.


Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.

More information about the freebsd-fs mailing list