0

We suppose to have a partition of 100Gb filled up by 75Gb of data.

We want to reduce it by 20Gb.

  • Does resize2fs move the 75Gb of data to the remaining 80Gb, and then resize the partition? In other words: are the data preserved?
  • If yes, is that valid for LVM too?

Thank you so much!

Improve this question

1 Answer 1

Reset to default
3

Yes, resize2fs moves data as needed (at least on ext4). That means that lvreduce -r (the -r is critical) is safe as well, because it first calls resize2fs via fsadm. Note that ext4 can shrink only in offline mode (when unmounted); trying to do it while mounted should just error out.

Of course, "safe" is only if there are no bugs, power isn't cut in the middle, etc. So you should still have backups.

BTW: roaima informs me that resize2fs actually syncs after each write, I presume that's to be safe in case of power failure. That'd of course depend on sync actually fully working, which it doesn't always (sometimes disk and especially SSDs do not handle power failures well). That also means that eatmydata (which prevents sync) can speed it up a bit — something roaima has tried — with of course making it much less safe if any failure occurs.

Improve this answer
5
  • One of the reasons resize2fs is slow is that it performs a sync after every write. (Use strace to watch this going on.) I've used eatmydata on a system with a UPS to speed this up somewhat.
    – roaima
    Oct 3, 2019 at 18:36
  • @roaima Interesting, possibly it is safe, then, if power is cut in the middle. At least if there are no bugs (including disk firmware or hardware ones).
    – derobert
    Oct 3, 2019 at 19:45
  • Possibly, yes. I wouldn't want to be in a position of needing to find out retrospectively though.
    – roaima
    Oct 3, 2019 at 20:19
  • Having a backup is always a good idea. 70GB isn't so much data these days that you couldn't make a dd or tar backup of the filesystem first.
    – LustreOne
    Oct 4, 2019 at 0:08
  • 1
    If a backup is available, the question arises whether reformatting and restoring from backup is faster than the resize - it really depends on how much data needs to be moved from the end of the filesystem. There was a patch patchwork.ozlabs.org/patch/960766 that allowed setting a high watermark for block allocations so that you could "drain" the top of the filesystem while mounted (eg. via e4defrag), to minimize the offline time for the resize, but it was never landed.
    – LustreOne
    Oct 4, 2019 at 0:16

You must log in to answer this question.

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