Thomas E. Zander wrote: > Hi, > > On Wed, 20. Jul 2005, at 6:57 -0500, Eric Anderson wrote > according to [Re: mksnap_ffs takes 4-5 minutes?]: > > >>A 2tb filesystem with the standard newfs options takes about 30 minutes >>to mksnap.. That's unusable really, because the filesystem is suspended >>for so long. Even empty 2tb filesystems take forever, so it's related >>to the amount of inodes. >> >>How can we make this snappier? > > > For the moment we can workaround by setting inode density appropriately > when creating the fs. However this is only feasible if you know what > your users are going to do with the fs; it also doesn't help when you > *need* a large fs containing many small files. > In the long run, dynamic inode (de)allocation would be nice to have. It doesn't seem to make a difference on how much of the filesystem is actually used. It seems to be dependent on how many inodes there are, or maybe more appropriately, how many cylinder groups. > Also...what about the 'preparation' time for snapping? IIRC McKusick > said that the lion's share of snapping time is used to delay pending > transactions before actually doing the snap. > There are quite some scenarios in which you can be certain that there > is no file opened for writing, so a snap could be taken immediately. > Would it be feasible to implement this feature? Or am I completely > wrong? The snap seemed to suspend the filesystem nearly immediately, and kept it suspended for quite some time - I would say probably more than half the time. In order for snapshots to be very useful, it must work on large filesystems (100GB+) in a reasonable amount of time (a few seconds would be ok). I know for certain that one test filesystem (2Tb) had nothing on it, no processess using the filesystem at all, and it took well over an hour to run mksnap on it. Maybe mksnap is broken somehow? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------Received on Fri Jul 22 2005 - 10:16:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:39 UTC