All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Zarochentsev <zam@namesys.com>
To: David Greaves <david@dgreaves.com>
Cc: reiserfs-list@namesys.com
Subject: Re: How long will a shrinkfs take?
Date: Fri, 11 Jun 2004 12:53:50 +0400	[thread overview]
Message-ID: <20040611085350.GR8091@backtop.namesys.com> (raw)
In-Reply-To: <40C96D57.2030208@dgreaves.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.

      reply	other threads:[~2004-06-11  8:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 20:13 How long will a shrinkfs take? David Greaves
2004-06-10 20:54 ` Alex Zarochentsev
2004-06-11  8:29   ` David Greaves
2004-06-11  8:53     ` Alex Zarochentsev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040611085350.GR8091@backtop.namesys.com \
    --to=zam@namesys.com \
    --cc=david@dgreaves.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.