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, ""...,
4096) = 4096
lseek(3, 4675072176128, SEEK_SET) = 4675072176128
read(3, "355A350320009271371M206177N~20633M350321 0"...,
4096) = 4096
lseek(3, 42978254848, SEEK_SET) = 42978254848
read(3, ""...,
4096) = 4096
lseek(3, 42978238464, SEEK_SET) = 42978238464
write(3, "355A350320009271371M364Y4N20020633M350321 0"...,
4096) = 4096
lseek(3, 4675072180224, SEEK_SET) = 4675072180224
read(3, "355A350320009271371M206177N~20633M350331 0"...,
4096) = 4096
lseek(3, 4675072163840, SEEK_SET) = 4675072163840
write(3, "355A350320009271371M206177N20020633M35032 10"...,
4096) = 4096

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32719 root 20 0 785m 768m 792 R 98 20.0 2443:18 resize2fs

$ sudo resize2fs /dev/mapper/data-data 3000G
resize2fs 1.41.11 (14-Mar-2010)
Resizing the filesystem on /dev/mapper/data-data to 786432000 (4k) blocks.

Time passes.

It's an LVM comprising 4x2TB disks in RAID10 and 4x500GB in RAID10.

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] [raid6]
[raid5] [raid4]
md1 : active raid10 sdi1[0] sdg1[1] sdf1[3] sdh1[2]
976767872 blocks 64K chunks 2 near-copies [4/4] [UUUU]

md0 : active raid10 sda1[2] sdc1[3] sdb1[1] sdd1[0]
3907023872 blocks 64K chunks 2 near-copies [4/4] [UUUU]

Disks are 7200RPM SATA disks.

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

Cheers,
Al.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

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

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

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

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Hi Ted,

Thanks for the prompt reply.

On 24 June 2011 15:27, Ted Ts'o <tytso@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.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

On 24 June 2011 15:56, Alan Pope <alan@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@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.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users