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: > > > >>Hi, > >> > >>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. > >> > >>So: > >> - 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. > > > >Kris > > > > > 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. Kris
pgp9vyECdpRSr.pgp
Description: PGP signature
