EXT3 Users Mailing List

Alan Pope | 24 Jun 2011 11:48

How long should resize2fs take?

Hullo!

First mail, sorry if this is the wrong place for this kind of
question. I realise this is a "piece of string" type question.

tl;dr version: I have a resizefs shrinking an ext4 filesystem from
~4TB to ~3TB and it's been running for ~2 days. Is this normal?

Strace shows lots of:-

lseek(3, 42978250752, SEEK_SET)         = 42978250752
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 4675072176128, SEEK_SET)       = 4675072176128
read(3, "\355A\350\3\0\20\0\0009\271\371M\206\177\0N~\206\33M\0\0\0\0\350\3\2\0\10\0\0\0"...,
4096) = 4096
lseek(3, 42978254848, SEEK_SET)         = 42978254848
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 42978238464, SEEK_SET)         = 42978238464
write(3, "\355A\350\3\0\20\0\0009\271\371M\364Y\4N\200\206\33M\0\0\0\0\350\3\2\0\10\0\0\0"...,
4096) = 4096
lseek(3, 4675072180224, SEEK_SET)       = 4675072180224
read(3, "\355A\350\3\0\20\0\0009\271\371M\206\177\0N~\206\33M\0\0\0\0\350\3\3\0\10\0\0\0"...,
4096) = 4096
lseek(3, 4675072163840, SEEK_SET)       = 4675072163840
write(3, "\355A\350\3\0\20\0\0009\271\371M\206\177\0N\200\206\33M\0\0\0\0\350\3\2\0\10\0\0\0"...,
4096) = 4096

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

(Continue reading)

headers

Ted Ts'o | 24 Jun 2011 16:27

Re: How long should resize2fs take?

On Fri, Jun 24, 2011 at 10:48:51AM +0100, Alan Pope wrote:
> Hullo!
> 
> First mail, sorry if this is the wrong place for this kind of
> question. I realise this is a "piece of string" type question.
> 
> tl;dr version: I have a resizefs shrinking an ext4 filesystem from
> ~4TB to ~3TB and it's been running for ~2 days. Is this normal?

Shrinking a file system can take a long time; it depends on how many
files are using space in the part of the file system that needs to be
evacuated for the shrink to take place.

> It's ~2TB full of data which is mostly rsnapshots of lots of remote
> hosts, so lots of little files.

Yes, that will take longer.  Resize2fs is engineered for safety, which
means it copies a lot of blocks, and then it updates the inodes, and
then copies more blocks, and then updates the inode involved, etc.  So
it's a fairly seeky operation that can take a while.

Most of the time people are growing their file systems, not shrinking
them, so we haven't done a huge amount of optimization for speed in
the shrink case.

Regards,

					- Ted

headers

Alan Pope | 24 Jun 2011 16:56

Re: How long should resize2fs take?

Hi Ted,

Thanks for the prompt reply.

On 24 June 2011 15:27, Ted Ts'o <tytso <at> mit.edu> wrote:
> Yes, that will take longer.  Resize2fs is engineered for safety, which
> means it copies a lot of blocks, and then it updates the inodes, and
> then copies more blocks, and then updates the inode involved, etc.  So
> it's a fairly seeky operation that can take a while.
>

Is it a process that could be terminated relatively safely? Or is it
just a case of "sit tight"?

Al.

headers

Alan Pope | 25 Jun 2011 10:29

Re: How long should resize2fs take?

On 24 June 2011 15:56, Alan Pope <alan <at> popey.com> wrote:
> Is it a process that could be terminated relatively safely? Or is it
> just a case of "sit tight"?
>

I sat tight and it finished okay.

alan <at> ubuntuserver:~$ sudo resize2fs /dev/mapper/data-data 3000G
[sudo] password for alan:
resize2fs 1.41.11 (14-Mar-2010)
Resizing the filesystem on /dev/mapper/data-data to 786432000 (4k) blocks.
The filesystem on /dev/mapper/data-data is now 786432000 blocks long.

Thanks,
Al.