[RndTbl] shrink partitions

[Michael Doob]

Is gparted useful? My recollection is that it is pretty good at what you want to do.

Cheers,
Michael

On 16-03-31 12:00 PM, roundtable-request at muug.mb.ca wrote:
> Send Roundtable mailing list submissions to
> 	roundtable at muug.mb.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.muug.mb.ca/mailman/listinfo/roundtable
> or, via email, send a message with subject or body 'help' to
> 	roundtable-request at muug.mb.ca
>
> You can reach the person managing the list at
> 	roundtable-owner at muug.mb.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Roundtable digest..."
>
>
> Today's Topics:
>
>     1. shrink to smaller disk, offsite (Trevor Cordes)
>     2. Re: shrink to smaller disk, offsite (Gilles Detillieux)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 Mar 2016 20:56:08 -0500
> From: Trevor Cordes <trevor at tecnopolis.ca>
> To: MUUG RndTbl <roundtable at muug.mb.ca>
> Subject: [RndTbl] shrink to smaller disk, offsite
> Message-ID: <20160331015608.GA22087 at pog.tecnopolis.ca>
> Content-Type: text/plain; charset=us-ascii
>
> I have an interesting problem.
>
> Linux box.
> /, /boot, swap on 3 RAID1 partitions
> 2 disks
>
> currently RAID is degraded, just using 1 750G disk.
> / (ext3) is 700G, only 200G used.
>
> No LVM.
>
> I added a 500G SSD.  I want that to be the new 2nd RAID1 disk.
>
> I need to shrink / to be ~450G before I can do this.
>
> resize2fs can only do shrink on unmounted.  That's a problem.  RAID1 can
> shrink the RAID block dev once I get the fs shrunk, so that's not a
> problem.
>
> I'm offsite and want to find a way to do this without going onsite and
> using single-user mode or a boot cd.
>
> Options?
>
> I guess I could make a new, smaller RAID1 / on the SSD, quiet down all
> services, and do a cp -a or cpio or something?  Then get the system to
> boot off the new / and ignore the old one, and reboot.  Besides in theory,
> has anyone actually do a whole cpio or cp -a of an entire *running* / and
> been successful?  Sample command lines?  I guess nowadays there would be
> zero dev files that need to be copied because udev recreates them all?  So
> it's literally just files, dirs, links and fifos that need copying?
>
> Any options using just ext3 and mdadm tools?  Surely there must be some
> way... unless the no-shrink-mounted makes that impossible.
>
> Maybe I'm missing something.
>
> Thanks!
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 31 Mar 2016 11:47:08 -0500
> From: Gilles Detillieux <grdetil at scrc.umanitoba.ca>
> To: roundtable at muug.mb.ca
> Subject: Re: [RndTbl] shrink to smaller disk, offsite
> Message-ID: <56FD548C.9010702 at scrc.umanitoba.ca>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> It's been a while since I've had to do this, but I have successfully
> replicated a live root volume on a few occasions using rsync. It could
> be as simple as doing this:
>
>     rsync  -aHXx /.  /mnt/newdisk/.
>
> I've adopted the "/." at the end of both paths to rsync as a defensive
> measure because it can make some funky assumptions about where you want
> source directories put in the target directory otherwise. I've often
> ended up with the target having an extra level of directory when I tell
> rsync to copy one directory to another without the /. at the end. The
> advantage of using rsync is that you can rerun it again to more quickly
> update the target if you suspect the source changed during the first
> copy, which can happen even on a relatively quiet system. To make the
> subsequent update even quicker, you can just run it on directories that
> are likely to have changed, e.g. /etc.
>
> I don't recall if I had to play around with --exclude options to avoid
> paths I didn't want traversed, or if the -x took care of all of these. I
> do recall that on a few occasions I played it safe by using a for loop
> to only copy specific subdirectories and avoid things like /sys and
> /proc altogether, but that was a bit more complicated and error-prone
> (easy to miss something important).
>
> Note that if you're using SELinux on your system, you'll want to verify
> that the target's contexts are correctly set, and chcon any that aren't.
> rsync with the -X option should copy contexts accurately, but you may
> want to manually override the context for any mount points on the target
> volume, and make sure the volume's root directory is set to
> system_u:object_r:root_t. ls -Zld dir  is the way I examine contexts (in
> addition to modes & ownership).
>
> Hope this helps.
>
> Gilles
>
> On 2016-03-30 20:56, Trevor Cordes wrote:
>> I have an interesting problem.
>>
>> Linux box.
>> /, /boot, swap on 3 RAID1 partitions
>> 2 disks
>>
>> currently RAID is degraded, just using 1 750G disk.
>> / (ext3) is 700G, only 200G used.
>>
>> No LVM.
>>
>> I added a 500G SSD.  I want that to be the new 2nd RAID1 disk.
>>
>> I need to shrink / to be ~450G before I can do this.
>>
>> resize2fs can only do shrink on unmounted.  That's a problem.  RAID1 can
>> shrink the RAID block dev once I get the fs shrunk, so that's not a
>> problem.
>>
>> I'm offsite and want to find a way to do this without going onsite and
>> using single-user mode or a boot cd.
>>
>> Options?
>>
>> I guess I could make a new, smaller RAID1 / on the SSD, quiet down all
>> services, and do a cp -a or cpio or something?  Then get the system to
>> boot off the new / and ignore the old one, and reboot.  Besides in theory,
>> has anyone actually do a whole cpio or cp -a of an entire *running* / and
>> been successful?  Sample command lines?  I guess nowadays there would be
>> zero dev files that need to be copied because udev recreates them all?  So
>> it's literally just files, dirs, links and fifos that need copying?
>>
>> Any options using just ext3 and mdadm tools?  Surely there must be some
>> way... unless the no-shrink-mounted makes that impossible.
>>
>> Maybe I'm missing something.
>>
>> Thanks!
>> _______________________________________________
>> Roundtable mailing list
>> Roundtable at muug.mb.ca
>> http://www.muug.mb.ca/mailman/listinfo/roundtable

-- 
------------------------------------------------------------------
Michael Doob                    Telephone: (204) 474-9796
Department of Mathematics       Fax: (204) 474-7606
University of Manitoba          email: Michael_Doob at umanitoba.ca
Winnipeg, MB, Canada R3T 2N2
------------------------------------------------------------------