From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Zarochentsev Subject: Re: How long will a shrinkfs take? Date: Fri, 11 Jun 2004 12:53:50 +0400 Message-ID: <20040611085350.GR8091@backtop.namesys.com> References: <40C8C0EF.7060704@dgreaves.com> <20040610205419.GQ8091@backtop.namesys.com> <40C96D57.2030208@dgreaves.com> Mime-Version: 1.0 Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com Content-Disposition: inline In-Reply-To: <40C96D57.2030208@dgreaves.com> List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Greaves Cc: reiserfs-list@namesys.com On Fri, Jun 11, 2004 at 09:29:11AM +0100, David Greaves wrote: > Alex Zarochentsev wrote: > > >On Thu, Jun 10, 2004 at 09:13:35PM +0100, David Greaves wrote: > > > > > >>Hi > >> > >>I have a 1Tb reiserfs that I want to shrink to 500Gb > >>400Gb of data is used. > >> > >>Any estimates as to how long this will take? > >>Sustained I/O is about 33Mb/s at the fs level, 44 Mb/s at the lv level > >>and 65Mb/s at the md0 level. > >> > >> > > > >ReiserFs shrinker reads all tree nodes as fsck does (reiserfsck --check > >may be > >used for rough estimation) plus shrinker writes relocated nodes (this > >highly > >depends on how many nodes are above 500GB boundary). > > > > > OK - well I know that fsck --check is of the order of minutes rather > than hours (did that rather too recently ;) ) > > So if I asume even spread, 50% is above so 200 Gb needs reading + then > writing so say 1Gb/min = 3-4 hours > > OK ta. > > BTW, is resizefs safely interruptible? So can I run it for a couple of > hours, interrupt, fsck, remount and do it again? > (The system's in use and I only get short windows when I can do this > kind of thing) no. interrupting it is not safe. fs errors are not so serious, but bitmap content does not match relocated tree so fsck would suggest --rebuild-tree. > I understand that if this happens the fs won't have been resized. > > I envisage the behaviour to be: > 1 calc new top boundary > 2 scan for files (nodes) with data above boundary it scans internal reiserfs tree, not fs tree. > 3 foreach file > 3.1 copy data below boundary > 3.2 change node to reflect new position > 3.3 mark old space as free > 4 set new top boundary > > most of the time being spent in 3. > > David > > >Anyway running reiserfsck --check before shrinking is a good practice. > > > > > > > >>(I didn't expect the fs to be so slow so I'm going to try a few tuning > >>params on the new 500Gb space before copying over the data and growing > >>back to a Tb) > >> > >>Is it proportional to the amount of shrinkage (ie 2 hrs to reduce by > >>50G, 20 hrs to reduce by 500Gb) > >> > >>David -- Alex.