What does resize2fs command do when we extend or reduce a Logical volume. Is the function same or different while using lvextend and lvreduce commands ?

  • I am looking for explicit difference in the functioning of the resize2fs command while reducing and extending the file system Sep 23, 2015 at 17:11

1 Answer 1


There are actually four different behaviors resize2fs can have (one of them trivial). It depends on if the filesystem is mounted or unmounted and if you're shrinking or extending.

  1. Mounted, Extending

    Here, resize2fs attempts an online resize. More or less, this just tells the kernel to do the work. The kernel then begins writing additional filesystem metadata on the newly available storage. You can continue to use the filesystem as this happens.

    Note that really old ext3 filesystems may not support online resize. You'll have to unmount the old filesystem to extend.

  2. Unmounted, Extending

    This time, resize2fs does the work instead of the kernel. Mostly this consists of writing additional filesystem metadata to the newly available storage.

  3. Mounted, Shrinking

    This isn't supported. It should just print out an error. This is the trivial behavior.

  4. Unmounted, Shrinking

    This is the most time consuming one, and also the most dangerous (though it still should be reasonably safe). If possible (e.g., there is sufficient space), resize2fs makes the filesystem use only the first size bytes of the storage. It does this by moving both filesystem metadata and your data around. After it completes, there will be unused storage at the end of the block device (logical volume), unused by the filesystem.

lvextend and lvreduce change the size of the logical volume. They can additionally change the size of the filesystem if given the -r option, which is probably the right way to go, especially with reducing. Accidentally giving the wrong size to lvreduce is an unfortunately easy way to lose data; -r prevents this (by ensuring that resize2fs is told the same size).

  • thanks for your input and breaking it down much more completely then I was aware of.
    – nomadrc
    Sep 23, 2015 at 17:33
  • Thanks. (1) for shrinking, does resize2fs defragment the files in the filesystem, without changing or removing existing files in the filesystem? (2) for extending, either kernel or resize2fs will write "additional filesystem metadata on the newly available storage". What is the additional filesystem metadata? Does writing it to a filesystem create new files, and why does writing it to a filesystem not cause any problem?
    – Tim
    Feb 18, 2019 at 15:49
  • @Tim I doubt it defragments files when shrinking, it does move them to defragment free space (all to the end). It's possible that leads to some incidental defragmentation (or the opposite). (2) additional metadata is mostly inode tables. Same kind of metadata mkfs writes. It doesn't cause an issue because extending storage is part of the design of the filesystem (and indeed is done by the filesystem code).
    – derobert
    Feb 18, 2019 at 16:45
  • Thanks. for extending, either kernel or resize2fs write additional filesystem metadata all over the newly available storage?
    – Tim
    Feb 18, 2019 at 16:51
  • @Tim not every sector of course, but they're distributed evenly across the filesystem. So it's a bunch of different spots, not just e.g., one contiguous area.
    – derobert
    Feb 18, 2019 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .