Aren't there already plenty of partitioning tools like fdisk, cfdisk(nice curses environment) or sfdisk(scriptable)? The downside of Gparted is that it's not a CLI program, other that that it's very useful in my opinion. For "sliding" the file-system it uses some sort of internal algorithm according to log file:
move file system to the right 05:48:52 ( SUCCESS ) perform read-only test 01:54:58 ( SUCCESS ) using internal algorithm read 611.40 GiB finding optimal block size read 16.00 MiB using a block size of 2.00 MiB 00:00:00 ( SUCCESS ) 16.00 MiB of 16.00 MiB read 0.215304 seconds read 16.00 MiB using a block size of 4.00 MiB 00:00:00 ( SUCCESS ) 16.00 MiB of 16.00 MiB read 0.250469 seconds read 16.00 MiB using a block size of 8.00 MiB 00:00:01 ( SUCCESS ) 16.00 MiB of 16.00 MiB read 0.215766 seconds read 16.00 MiB using a block size of 16.00 MiB 00:00:00 ( SUCCESS ) 16.00 MiB of 16.00 MiB read 0.253064 seconds optimal block size is 2.00 MiB read 611.34 GiB using a block size of 2.00 MiB 01:54:57 ( SUCCESS ) 611.34 GiB of 611.34 GiB read 611.40 GiB (656486170624 B) read perform real move 03:53:54 ( SUCCESS ) using internal algorithm copy 611.40 GiB finding optimal block size copy 16.00 MiB using a block size of 1.00 MiB 00:00:01 ( SUCCESS ) 16.00 MiB of 16.00 MiB copied 0.988301 seconds copy 16.00 MiB using a block size of 2.00 MiB 00:00:00 ( SUCCESS ) 16.00 MiB of 16.00 MiB copied 0.53326 seconds copy 16.00 MiB using a block size of 4.00 MiB 00:00:01 ( SUCCESS ) 16.00 MiB of 16.00 MiB copied 0.598635 seconds copy 16.00 MiB using a block size of 8.00 MiB 00:00:01 ( SUCCESS ) 16.00 MiB of 16.00 MiB copied 0.530564 seconds copy 16.00 MiB using a block size of 16.00 MiB 00:00:00 ( SUCCESS ) 16.00 MiB of 16.00 MiB copied 0.522437 seconds optimal block size is 16.00 MiB copy 611.32 GiB using a block size of 16.00 MiB 03:53:51 ( SUCCESS ) 611.32 GiB of 611.32 GiB copied 611.40 GiB (656486170624 B) copied PS: thank you for this pv trick :) Martin Kuupäeval 25. aprill 2012 1:27 kirjutas Håkon Løvdal <[email protected]>: > On 24 April 2012 21:28, Martin T <[email protected]> wrote: >> I was fairly sure that parted is able to handle such operations, but >> for my surprise it's heading away from operations related to file >> systems.. In case one can't use Gparted, I guess the best option is >> to: > > I am not sure if this was supported, and the reason for removing > file system code from parted was that it was not maintained and > I think parts of it had known problems that were not fixed. So parted > is consolidating on its core business, partition management, and > then let file system specific programs do the file system operations. > Since parted also is available as a library it is possible to combine > partition management and file system operation in other programs, > like Gparted. > > >> 1) shrink the file system(resize2fs) and then partition(fdisk) towards >> the beginning >> 2) create a new partition(fdisk) and file system(mkfs.ext3) to the >> space which was freed in the first step >> 3) copy(cp -a) content of first file system to the second file >> system(the one which was created in step 2) >> 4) delete the first partition >> 5) associate the new partition with the correct mount point in /etc/fstab >> >> Any other options/suggestions for shrinking the partition and >> file-system in it starting from the beginning from the CLI? > > This sounds like a correct approach, although you can skip step 5 > if you use label or uuid instead of device file name to identify the > partition. > > Also while "cp -a" makes identical copies of files, it will not preserve > SELinux > information, so using a tar[1] pipe to copy is probably preferable. > If you pipe through pv[2] as well you get very nice progress information, e.g. > > (cd /mnt/source; tar cf - . ) | pv -s $(du -sb /mnt/source | awk > '{print $1}') | (cd /mnt/target; tar xf -) > > [1] > http://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index.html#id3037344 > [2] > http://www.ivarch.com/programs/pv.shtml > > BR Håkon Løvdal
