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.



_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to