Re: Resize2fs Questions
> On 31 Jan 2022, at 23:36, Andy Smith wrote: > Hello, > > On Mon, Jan 31, 2022 at 05:57:45PM +, Gareth Evans wrote: >>> On 31 Jan 2022, at 17:37, Andy Smith 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. Hi Andy, I'm afraid I replied before I'd thought through what I had in mind, which was, wrongly, that deleting a partition unlinks the files it contains. "Appearance of deletion" was a poor choice of words. I meant that unlinked files could be recovered (if not first overwritten), although deletion is indeed the appropriate term. Thinking of testdisk/photorec reminded me that I was thinking (and writing) wrongly in the first place. Thanks anyway for your explanation. Gareth > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting >
Re: Resize2fs Questions
Hello, On Mon, Jan 31, 2022 at 05:57:45PM +, Gareth Evans wrote: > > On 31 Jan 2022, at 17:37, Andy Smith 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
Re: Resize2fs Questions
> On 31 Jan 2022, at 18:03, Gareth Evans wrote: > > > >> On 31 Jan 2022, at 17:58, Gareth Evans wrote: >> >> >> On 31 Jan 2022, at 17:37, Andy Smith wrote: >>> >>> Hello, >>> >>> On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote: >>> On 31 Jan 2022, at 14:41, Martin McCormick >>> 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!
Re: Resize2fs Questions
> On 31 Jan 2022, at 17:58, Gareth Evans wrote: > > > >> On 31 Jan 2022, at 17:37, Andy Smith wrote: >> >> Hello, >> >> On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote: >> On 31 Jan 2022, at 14:41, Martin McCormick >> 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...
Re: Resize2fs Questions
> On 31 Jan 2022, at 17:37, Andy Smith wrote: > > Hello, > > On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote: On 31 Jan 2022, at 14:41, Martin McCormick 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?
Re: Resize2fs Questions
Hello, On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote: > > On 31 Jan 2022, at 14:41, Martin McCormick 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
Re: Resize2fs Questions
> On 31 Jan 2022, at 14:41, Martin McCormick 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?
Re: Resize2fs Questions
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 /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
