-1

man resize2fs says

The resize2fs program will resize ext2, ext3, or ext4 file systems. It can be used to enlarge or shrink an unmounted file system located on device. ... The size parameter specifies the requested new size of the filesystem

How do you choose a size parameter to specify to resize2fs? More specifically:

How is the size of a filesystem defined?

Does it count external fragmentation and/or internal fragmentation? If it doesn't count external fragmentation but counts internal fragmentation, the size of a filesystem should be the same, as long as resize2fs doesn't modify or remove the existing files.

Does it count the space for storing inodes and the space for root usage, such as defragmentation?

Do df's and gparted's "used" columns show the size of each file system? Can the "used" numbers be used for choosing a size parameter for resize2fs? Note that df's and gparted's "used" columns show different used numbers for the same partition, and not sure why.

Thanks.

4

The size of a file system, as used for resize2fs (and mke2fs and other similar tools) is the external size of the file system, i.e. the amount of space it occupies as viewed from the outside. The internal data structures of the file system don’t matter here. Everything in the file system — metadata, data, and unused space within the file system — fits within the file system’s size. This also includes any boot loader hosted in the same partition as the file system, where such a configuration is possible (it is with Ext2/3/4, not with XFS, for example).

The best way to determine the current size of a file system is to read it from the file system; for example, for ext2/3/4 file systems, you’d multiply the block count by the block size:

dumpe2fs -h /path/to/file/system | grep -E 'Block (count|size):'

By default, the size of a file system is usually the size of its container, e.g. its containing partition or logical volume. This is the value that resize2fs will use if you don’t specify a size explicitly. Specifying size is useful when you want to shrink a file system and its container: you’d start by running resize2fs with the target size, and then shrink the container (partition, logical volume, etc.) to match.

To determine the minimum size to which you can shrink a file system, the best approach is to use resize2fs itself:

resize2fs -M -P /path/to/file/system

will tell you how many blocks a minimal file system would occupy (preserving all the current contents); to determine the block size used, run

dumpe2fs -h /path/to/file/system | grep Block\ size

You can get the details of the calculation by adding -d 32:

resize2fs -d 32 -M -P /path/to/file/system

The maximum size of a file system is usually the size of its container (partition or logical volume). A file system which is in a partition or logical volume can never be bigger than the partition or logical volume; there can be additional constraints which limit the extent to which a file system can grow. (File systems stored in image files behave differently, resize2fs changes the file size to match the file system size, whether growing or shrinking.)

  • Thanks. (1) Since the size parameter doesn't mean the target used size in the partition of the file system, an resize2fs won't remove or modify existing files in any case, what is the purpose of the size parameter? (2) What is "the external size of the file system, i.e. the amount of space it occupies as viewed from the outside"? Does it count external fragmentation and/or internal fragmentation? Does it count the space for storing inodes and the space for root usage (defragmentation)? (3) Can df's and gparted's "used" columns be useful for choosing a size parameter for resize2fs? – Tim Feb 20 at 13:36
  • No, I don't, but I often check if you did. (1) "Everything in the file system — metadata and data — fits within the file system’s size." How about external fragmentation, i.e. the free space holes between files? I believe it counts internal fragmentation. (2) by resize, do you mean for terminal? – Tim Feb 20 at 14:19
  • (1) Sorry, feel difficulty understanding your analogy. I am surprised that you don't know about it, while it is understandable that I don't. external fragmentation means the free space in the partition is split into pieces by files (or parts of files). So does the size of a file system count the holes between files (or file parts)? – Tim Feb 20 at 14:39
  • Forget about partitions, we’re talking about file systems here. The space between files is still inside the file system, so yes, it’s part of the file system’s size. Otherwise a file system’s size would change as you add and remove files. – Stephen Kitt Feb 20 at 14:44
  • 1
    @炸鱼薯条德里克 I was trying to clarify that the file system’s size isn’t one of the “internal” sizes visible using df etc., to address Tim’s questions about fragmentation and so on. In my mind the underlying storage is a separate issue; when you look at the apparent size of a sparse file, you still see the full size (“space it occupies as viewed from the outside”). How can resize2fs “help you resize the container in just one run”? I thought that was fsadm. – Stephen Kitt Feb 21 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.