kris at obsecurity.org
Thu Jan 11 12:02:01 PST 2007
On Thu, Jan 11, 2007 at 11:25:34AM -0800, Scott Oertel wrote:
> Kris Kennaway wrote:
> >On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote:
> >>I got the following Filesystem:
> >>Filesystem Size Used Avail Capacity iused ifree %iused
> >>/dev/da0a 1.3T 422G 823G 34% 565952 182833470 0%
> >>Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb.
> >>The system is used as SMB/NFS server for my other systems here.
> >>I would like to make weekly snapshots, but manually running mksnap_ffs
> >>freezes access to the disk (I sort of expected that) but the process
> >>never terminates. So I let is sit overnight, but looking a gstat did not
> >>reveil any activity what so ever...
> >>The disk was not released, mksnap_ffs could not be terminated.
> >>And things resulted in me rebooting the system.
> >> - How long should I expect making a snapshot to take:
> >> 5, 15, 30min, 1, 2 hour or even more???
> >Yes :) Snapshots were not designed for use in this way (they were
> >designed to support background fsck and allow faster system recovery
> >after power failure), so they don't scale as well as you might like on
> >large filesystems.
> If snapshots were designed to support background fsck, then why did they
> not make it more scalable? If you can't create a snapshot without the
> system locking up, that means fsck won't be able to either, making
> background fsck worthless for systems with large storage.
locking up != taking a long time to complete. You haven't
differentiated between those two situations yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070111/44724182/attachment.pgp
More information about the freebsd-stable