problem creating filesystem snapshot

[Alex Zbyslaw]

Jon Falconer wrote:

>Greetings,
>
>I needed to dump the partitions on a running FreeBSD 6.1R system so I
>could duplicate them on a test server. The server is a Dell 2850 with the
>PERC 4e/Di RAID controller with 5 x 73GB disk array. So I thought I would
>try using the snapshot feature. I used the mksnap_ffs to create a snapshot
>of a 20GB partition. The command completed in about 15 - 20 seconds. I was
>then able to run dump against the new snap file and all seemed ok. I then
>tried the same thing on a 225GB partition. The mksnap_ffs command took
>over 30 minutes to complete. But every access to that partition after that
>just hung. I wanted to see the size of the snap file so I typed ls -l
>/home/.snap (where I had told mksnap_ffs to put the snap file) and it
>hung. Same thing from several logins. I figured I would have to reset the
>box so I typed sync, and that hung. All the time, access to other
>partitions was just fine (/, /usr, /var).
>
>All partitions (except /) were created with soft update enables (default
>when installing.) 
>
>The questions. Is there anything magic about the /xxx/.snap directory in
>each partition? When I created the snap file for the 20GB partition, I did
>not put it inside the /xxx/.snap directory, and it worked fine. Is there
>some partition size restrictions?
>
>  
>
You don't need to make snapshots yourself to dump the filesystems.  Dump 
will do it for you:

     -L      This option is to notify dump that it is dumping a live 
file sys-
             tem.  To obtain a consistent dump image, dump takes a 
snapshot of
             the file system in the .snap directory in the root of the file
             system being dumped and then does a dump of the snapshot.  The
             snapshot is removed when the dump is complete.  This option is
             ignored for unmounted or read-only file systems.  If the .snap
             directory does not exist in the root of the file system being
             dumped, a warning will be issued and the dump will revert 
to the
             standard behavior.  This problem can be corrected by creating a
             .snap directory in the root of the file system to be 
dumped; its
             owner should be ``root'', its group should be ``operator'', and
             its mode should be ``0770''.

There were problems reported with snapshots of large filesystems in 
earlier releases but I have no idea of the status of any fixes/changes 
or what constituted "large".  You could try sdearching the PRs from the 
FreeBSD web site.  FWIW a 95Gb partition under 5.4 snapshots in ~30 
seconds for me and there are no lockup issues to date.  A 20Gb partition 
I would expect to take a handful of seconds.  There were also issues 
about multiple snapshots of the same filesystem causing problems.  Did 
you make multiple snapshots when you were testing and did you delete 
them when you had finished with them?

I don't believe there is anything special about .snap directory - just a 
convention and it's where dump will make its snapshots.

--Alex

PS We use snapshots on the same hardware as you - 2850 & PERC4e/Di but 
with RAID-1 rather than whatever you are running.  I don't think any of 
that makes any difference though.