Date: Fri, 23 Jun 2006 09:55:16 +0100 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Jon Falconer <jfalconer@puc.edu> Cc: questions@freebsd.org Subject: Re: problem creating filesystem snapshot Message-ID: <449BAC74.7050903@dial.pipex.com> In-Reply-To: <Pine.BSI.4.05L.10606221042020.19399-100000@ecf2.puc.edu> References: <Pine.BSI.4.05L.10606221042020.19399-100000@ecf2.puc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?449BAC74.7050903>