6

I'm asking because, for example,

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Features

states that EXT3 can be shrunk online. But when I click on the reference:

"Offline growing/shrinking as well as online growing"

So what is the truth? Can someone post a small list of filesystems that currently be shrunk online?

Faheem Mitha
  • 35,108
LanceBaynes
  • 40,135
  • 97
  • 255
  • 351
  • 1
    This chart is confusing as it implicitly assumes there is a single file system per volume. This isn't true for ZFS volumes (zpools) that indeed cannot be shrink (yet?) but nevertheless ZFS file systems can be grown or shrink online. – jlliagre Nov 16 '11 at 08:33
  • 1
    Note from 2015: there is still no fs on linux which would be capable to do that. For ext2 there were some patches in the ancient times (yet before ext3). Reiserfs promised this, maybe if it gets the needed support it would be long ready now. – peterh Sep 02 '15 at 20:07

4 Answers4

7

Of the common filesystems used on Linux:

  • JFS and XFS cannot be shrunk at all. Nor can (AFAIK) FFS and UFS, even with Solaris or *BSD.
  • Ext2/ext3/ext4 and Reiserfs cannot shrink mounted filesystems.
  • Btrfs can shrink mounted filesystems.
Gilles 'SO- stop being evil'
  • 829,060
1

ZFS somewhat demonstrated growing or shrinking a file system is pointless.

A ZFS File system can but isn't required to have a predefined size. In the latter case, there is no need to shrink the filesystem given the fact there is no wasted space, unlike most if not all other file systems.

Of course, the underlying physical devices have a capacity limit but there is no need to add arbitrary limits.

jlliagre
  • 61,204
  • 2
    If it was really pointless: Suppose you have a LVM and you need to create another volume, but have no space for it. So you have to shrink the existing file system. You yould just do a lvresize - but what if there are data in the area you are cutting off from the volume? That's why you need to tell the file system to move it to somewhere safe, i.e. before the place you want to have the cut. That's exactly what shrinking does. For growing, you are right - theoretically, the FS could detect that the volume has more space than before and use it automatically. – glglgl Nov 16 '11 at 00:12
  • 1
    You postulate partitioning and reserving a fixed size of disk to file systems is mandatory. This is true for traditional file systems. However, ZFS shows it is an avoidable annoyance. Just like when you create a file, you do not reserve a fixed size of storage to it, ZFS datasets only use the space they need to store data. They do not preallocated free space unavailable to other filesystems (or volumes, snapshots, whatever). – jlliagre Nov 16 '11 at 08:23
  • 1
    Ok, but just to understand it: Step 1: add file of 4GB to a partition of 9GB, which gets put tu the start (let's say). Step 2: add another file of 4GB, being put to the end. Step 3: remove the first file. Step 4: shrink the file system to 5 GB. This Step 4 can only work if the data of the file are moved. Is there a tool which does this? Or does it happen automatically when removing the 1st file? I cannot imagine that... And this has nothing to do with preallocation or whatever. Data on disk have to be physically somewhere... – glglgl Nov 16 '11 at 08:51
  • 1
    I believe jlliagre is saying that space is already there. So once you remove the file its available for you to create another mountpoint with. So all the mountpoints in a pool share the total available space. In LVM terms think of a VG where new LV's always show the total space availble in the VG. So say 3 LV's in VG will all report the same space used. Adding a 4th LV will also show the same space used. – AndyM Nov 16 '11 at 09:04
  • 1
    Indeed. There is no need to move the second file content after removing the first file. When you remove a file, the space it was using is marked as free and usable for other files. ZFS uses the pool space the same way. Unlike with traditional file systems, there is no need for file systems blocks to be in contiguous areas isolated from the other file systems (or volumes). – jlliagre Nov 16 '11 at 10:39
  • 4
    @jlliagre I think you and glglgl are talking at cross-purposes. You're saying that you can have several ZFS volumes with flexible boundaries inside a given space. Sure, but that's not the question here. Suppose you have a 2TB disk, fully occupied by a more than half-empty ZFS filesystem. You suddenly realize that you need to split off 1TB of that disk to make an NTFS partition. Can you shrink the part of the disk that's allocated to ZFS? – Gilles 'SO- stop being evil' Nov 17 '11 at 02:00
  • 1
    No, and I already answered to that question in my comment to the original question. ZFS pools cannot yet be shrunk. However, there is still a way to do what you ask for. Just create a ZVOL and then layout an NTFS partition on it. Of course, that isn't going to help if I dual boot with Windows or any OS that doesn't support ZFS pools, but my volume would be usable remotely through iSCSI or locally to a VM. It will also add features not available on NTFS, like unlimited snapshots and clones. – jlliagre Nov 17 '11 at 12:29
1

It should be noted for posterity that https://en.wikipedia.org/wiki/Comparison_of_file_systems#Resize_capabilities has since been updated to list a number of file systems that do support online shrinking.

On Linux, apparently Btrfs supports it. There do appear to be some caveats, cf. other questions on the network:

AIX JFS2 can do this, cf. How to decrease the size of a logical volume/fs aix? Curiously enough, a quick search finds me no obvious proof that the Linux JFS2 port can do the same.

Josip Rodin
  • 1,138
1

I was able to shrink online rootfs on ReiserFS v3 using resize_reiserfs for testing. That was few years ago on some linux. But now I get "Can't shrink filesystem on-line.". I've heard, ext3 was shrinkable online in some cases with resize2fs, and it wasn't in other cases. I belive, this feature is very dangerous and unstable and can "accidently whole FS".

Senex
  • 11