Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #244864 > unrolled thread

Resize2fs Questions

Back to article view | Back to linux.debian.user

Contents

  Resize2fs Questions "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-31 15:50 +0100
    Re: Resize2fs Questions Andy Smith <andy@strugglers.net> - 2022-01-31 16:40 +0100
    Re: Resize2fs Questions Gareth Evans <donotspam@fastmail.fm> - 2022-01-31 18:30 +0100
      Re: Resize2fs Questions Andy Smith <andy@strugglers.net> - 2022-01-31 18:40 +0100
        Re: Resize2fs Questions Gareth Evans <donotspam@fastmail.fm> - 2022-01-31 19:00 +0100
          Re: Resize2fs Questions Gareth Evans <donotspam@fastmail.fm> - 2022-01-31 19:10 +0100
            Re: Resize2fs Questions Gareth Evans <donotspam@fastmail.fm> - 2022-01-31 19:20 +0100
          Re: Resize2fs Questions Andy Smith <andy@strugglers.net> - 2022-02-01 00:40 +0100
            Re: Resize2fs Questions Stefan Monnier <monnier@iro.umontreal.ca> - 2022-02-01 03:00 +0100

#244864 — Resize2fs Questions

I figured I would start a new topic as none of this pertains to
the previous messages I posted.

	I've got an almost 30-GB disk image of a working debian
installation for a Raspberry pi that I should be able to easily
squeeze on to a roughly 8 GB SSD card because it only takes up
10% of the 30-GB card and I think I am close but not there yet.
Because I hate drudgery with regards to syntax, I wrote a little
shell script that makes it easier to duplicate the same actions
and also makes it easy to show exactly what is happening so far.
The big image name is

rpi1_good.img

and it is 29 gb in size.  Here are the commands that work so far.

#!/bin/sh
#This resets everything for a new run.
  sudo losetup -d /dev/loop0
#copy a backup to the image name to start fresh.
sudo cp -p rpi1_good.img.bak rpi1_good.img
#This takes about half an hour.  Now, get to business.
    sudo losetup -P /dev/loop0 rpi1_good.img
#This should show 2 partitions on loop0 when successful.
sudo ls -l /dev/loop0*
#You get /dev/loop0p1 and p2
#e2fs is required to run before one can resize.
   sudo e2fsck -f /dev/loop0p2
#I should be telling resize2fs to squeeze everything in to a 7GB
#partition.
   sudo resize2fs /dev/loop0p2 +7G

	There are no complaints up to this point and resize
appeared to work so now it is time to reduce the size of
partition 2.

	This may be where things go off the track.

I run

sudo fdisk /dev/loop0

and fdisk tells me it is 29.9 GB which I expected since Partition
#2 should be mostly empty but for the OS and my login directory.

	I note that the starting sector for P2 is 137215 since
one must start at that sector and then I delete P2 and then add a
new partition which defaults to 2.

fdisk prompts for the first sector with a default of 2048 but I
type in 137215.  The last sector is in the 62-million range and I
want only 7 GB as the size so I type +7G and it takes that.

	I then type w to save the changes and there is no
complaint.

	The first hint of trouble is when you do fdisk -l
/dev/loop0.  The size count is still almost 30 GB but then a ray
of Sun in that P2 has a size of around 7 GB.

	I outwitted Murphy this time by using another file on my
computer as the target rather than the SSD card so that if it
went over 8 GB, nothing annoying would happen.

	I watched on another console as the size climbed past 5
GB, then 6 and 7 GB and then it was up past ten so it was going
to do the whole 30 GB if I hadn't stopped it.

	I am not sure what I missed but the manual page for
resize2fs warns you to use something like fdisk to trim off the
excess empty space which is what I thought I did.  I would also
have thought that the disk image file should have deflated like a
punctured air mattress but it didn't.

	I think I am almost there but obviously not yet.

Thanks in advance for ideas.

Martin

[toc] | [next] | [standalone]

#244867

Hello,

On Mon, Jan 31, 2022 at 08:40:49AM -0600, Martin McCormick wrote:
> #I should be telling resize2fs to squeeze everything in to a 7GB
> #partition.
>    sudo resize2fs /dev/loop0p2 +7G

[…]

> fdisk prompts for the first sector with a default of 2048 but I
> type in 137215.  The last sector is in the 62-million range and I
> want only 7 GB as the size so I type +7G and it takes that.
> 
> 	I then type w to save the changes and there is no
> complaint.
> 
> 	The first hint of trouble is when you do fdisk -l
> /dev/loop0.  The size count is still almost 30 GB but then a ray
> of Sun in that P2 has a size of around 7 GB.

What you have at this point is an image file that's 30 or so GB in
size with a partition table, small first partition, ~7GB second
partition and then nothing out to the end. 23GB or so of nothing.

You've resized your last partition but you haven't resized your
disk.

If this were an LVM LV containing a disk image, at this point I'd be
shrinking the LV itself. So, the analogous action for you is to
shrink your image file. You need to work out the last sector of your
second partition from your "fdisk -u -l" output, and use something
like "truncate -s <size-in-bytes> /path/to/your.img" to truncate it
down to the desired total size. Play around a bit. Leaving a few KiB
of empty space at the end isn't going to hurt.

> 	I am not sure what I missed but the manual page for
> resize2fs warns you to use something like fdisk to trim off the
> excess empty space which is what I thought I did.  I would also
> have thought that the disk image file should have deflated like a
> punctured air mattress but it didn't.

fdisk doesn't know what sort of device the disk is; its concern is
just things inside the disk like partition tables. So while fdisk or
parted can create and manipulate partitions, you need
device-specific tools to resize what might be an LVM, LUKS, a floppy
disk, etc etc - a lot of the time it not even being possible. Think
about shrinking the last partition on a HDD. fdisk can't alter the
physical construction of your HDD to have less capacity.

But for virtual abstractions like loop devices and LVL logical
volumes, there are tools to just shrink them. In the case of loop
file, just truncate the backing file. You might have to deregister
the loop device first; not sure.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#244877

> On 31 Jan 2022, at 14:41, Martin McCormick <martin.m@suddenlink.net> wrote:
> 
> #I should be telling resize2fs to squeeze everything in to a 7GB
> #partition.
>   sudo resize2fs /dev/loop0p2 +7G
> [...]
> then I delete P2 and then add a
> new partition which defaults to 2.

This seems to replace the partition containing the filesystem you've just resized with an empty one - doesn't it?

[toc] | [prev] | [next] | [standalone]

#244878

Hello,

On Mon, Jan 31, 2022 at 05:27:56PM +0000, Gareth Evans wrote:
> > On 31 Jan 2022, at 14:41, Martin McCormick <martin.m@suddenlink.net> wrote:
> > 
> > #I should be telling resize2fs to squeeze everything in to a 7GB
> > #partition.
> >   sudo resize2fs /dev/loop0p2 +7G
> > [...]
> > then I delete P2 and then add a
> > new partition which defaults to 2.
> 
> This seems to replace the partition containing the filesystem you've just resized with an empty one - doesn't it?

When you change a partition table it doesn't do anything to the
data on the disk, only the partition table. Every partition resizing
operation that only has to move the end position essentially does it
this way.

(If you have to move the start then the data has to be moved first)

If you were using parted then you might type:

resizepart 2 7g

which looks less scary, but does exactly the same thing.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#244879

> On 31 Jan 2022, at 17:37, Andy Smith <andy@strugglers.net> wrote:
> 
> Hello,
> 
> On Mon, Jan 31, 2022 at 05:27:56PM +0000, Gareth Evans wrote:
>>>> On 31 Jan 2022, at 14:41, Martin McCormick <martin.m@suddenlink.net> wrote:
>>> 
>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>> #partition.
>>>  sudo resize2fs /dev/loop0p2 +7G
>>> [...]
>>> then I delete P2 and then add a
>>> new partition which defaults to 2.
>> 
>> This seems to replace the partition containing the filesystem you've just resized with an empty one - doesn't it?
> 
> When you change a partition table it doesn't do anything to the
> data on the disk, only the partition table. Every partition resizing
> operation that only has to move the end position essentially does it
> this way.
> 
> (If you have to move the start then the data has to be moved first)
> 
> If you were using parted then you might type:
> 
> resizepart 2 7g
> 
> which looks less scary, but does exactly the same thing.
> 
> Cheers,
> Andy
> 
> -- 
> https://bitfolk.com/ -- No-nonsense VPS hosting
> 

Hi Andy, I appreciate the data doesn't go anywhere, but...

>> then I delete P2 and then add a
>> new partition which defaults to 2.

doesn't that at least result in the appearance of deletion (an empty partition) if done after the resizing?

[toc] | [prev] | [next] | [standalone]

#244880

> On 31 Jan 2022, at 17:58, Gareth Evans <donotspam@fastmail.fm> wrote:
> 
> 
> 
>> On 31 Jan 2022, at 17:37, Andy Smith <andy@strugglers.net> wrote:
>> 
>> Hello,
>> 
>> On Mon, Jan 31, 2022 at 05:27:56PM +0000, Gareth Evans wrote:
>>>>>> On 31 Jan 2022, at 14:41, Martin McCormick <martin.m@suddenlink.net> wrote:
>>>>> 
>>>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>>>> #partition.
>>>>> sudo resize2fs /dev/loop0p2 +7G
>>>>> [...]
>>>>> then I delete P2 and then add a
>>>>> new partition which defaults to 2.
>>> 
>>> This seems to replace the partition containing the filesystem you've just resized with an empty one - doesn't it?
>> 
>> When you change a partition table it doesn't do anything to the
>> data on the disk, only the partition table. Every partition resizing
>> operation that only has to move the end position essentially does it
>> this way.
>> 
>> (If you have to move the start then the data has to be moved first)
>> 
>> If you were using parted then you might type:
>> 
>> resizepart 2 7g
>> 
>> which looks less scary, but does exactly the same thing.
>> 
>> Cheers,
>> Andy
>> 
>> -- 
>> https://bitfolk.com/ -- No-nonsense VPS hosting
>> 
> 
> Hi Andy, I appreciate the data doesn't go anywhere, but...
> 
>>> then I delete P2 and then add a
>>> new partition which defaults to 2.
> 
> doesn't that at least result in the appearance of deletion (an empty partition) if done after the resizing?

Do you mean creating a new partition 'around' the data makes it accessible again?  That would make sense re eg what testdisk seems to do...

[toc] | [prev] | [next] | [standalone]

#244881

> On 31 Jan 2022, at 18:03, Gareth Evans <donotspam@fastmail.fm> wrote:
> 
> 
> 
>> On 31 Jan 2022, at 17:58, Gareth Evans <donotspam@fastmail.fm> wrote:
>> 
>> 
>> 
>>>> On 31 Jan 2022, at 17:37, Andy Smith <andy@strugglers.net> wrote:
>>> 
>>> Hello,
>>> 
>>> On Mon, Jan 31, 2022 at 05:27:56PM +0000, Gareth Evans wrote:
>>>>>>> On 31 Jan 2022, at 14:41, Martin McCormick <martin.m@suddenlink.net> wrote:
>>>>>> 
>>>>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>>>>> #partition.
>>>>>> sudo resize2fs /dev/loop0p2 +7G
>>>>>> [...]
>>>>>> then I delete P2 and then add a
>>>>>> new partition which defaults to 2.
>>>> 
>>>> This seems to replace the partition containing the filesystem you've just resized with an empty one - doesn't it?
>>> 
>>> When you change a partition table it doesn't do anything to the
>>> data on the disk, only the partition table. Every partition resizing
>>> operation that only has to move the end position essentially does it
>>> this way.
>>> 
>>> (If you have to move the start then the data has to be moved first)
>>> 
>>> If you were using parted then you might type:
>>> 
>>> resizepart 2 7g
>>> 
>>> which looks less scary, but does exactly the same thing.
>>> 
>>> Cheers,
>>> Andy
>>> 
>>> -- 
>>> https://bitfolk.com/ -- No-nonsense VPS hosting
>>> 
>> 
>> Hi Andy, I appreciate the data doesn't go anywhere, but...
>> 
>>>> then I delete P2 and then add a
>>>> new partition which defaults to 2.
>> 
>> doesn't that at least result in the appearance of deletion (an empty partition) if done after the resizing?
> 
> Do you mean creating a new partition 'around' the data makes it accessible again?  That would make sense re eg what testdisk seems to do...

Sorry - wasn't thinking!

[toc] | [prev] | [next] | [standalone]

#244889

Hello,

On Mon, Jan 31, 2022 at 05:57:45PM +0000, Gareth Evans wrote:
> > On 31 Jan 2022, at 17:37, Andy Smith <andy@strugglers.net> wrote:
> Hi Andy, I appreciate the data doesn't go anywhere, but...
> 
> >> then I delete P2 and then add a
> >> new partition which defaults to 2.
> 
> doesn't that at least result in the appearance of deletion (an empty partition) if done after the resizing?

A partition table is just basically a list of start and end
positions of partitions.

When you "delete a partition" all you've done is removed the entry
in the table, but the data that belongs to the partition you just
deleted is still on the disk in the place where it always was.

If you then put back a partition the same as it was before (or
bigger), it will then show up as a valid partition again.

In the case of a grow, you then tell your FS or whatever to use the
empty space that's now at the end.

In the case of a shrink, you already told your FS (or whatever) to
create a gap between the end of the FS and the end of the partition,
so after deleting that partition you can add a "new" partition that
has an end position that matches the end of the shrunken FS.

If this does not make it clear that "deleting a partition" in fdisk
or parted or whatever is a perfectly normal thing to do that doesn't
in itself trash your data, I don't know how better to explain it and
you will have to elaborate as to where the confusion lies. I don't
know what "the appearance of deletion" means to you in this context
or why you think it harms any data that is on a disk.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#244893

> When you "delete a partition" all you've done is removed the entry
> in the table, but the data that belongs to the partition you just
> deleted is still on the disk in the place where it always was.

Note that this is usually the case in tools like `fdisk` but it's
usually not necessarily the case with all tools (macOS tools don't seem
to offer such a functionality, for example).


        Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web