From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Moving partitionless (hypothetical) (Was: Re: [gentoo-user] Process to resize ext3 file system at the command line? )
Date: Thu, 17 Nov 2011 12:45:48 -0500 [thread overview]
Message-ID: <CA+czFiA71zrEev+_vV9-cD8RB_AipeTKD7PkbkZdGdGrjUznyA@mail.gmail.com> (raw)
On Thu, Nov 17, 2011 at 12:25 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 17 Nov 2011 09:01:46 -0800, Mark Knecht wrote:
>
>> I'm pretty sure I've got the command set right to do the RAID-1 to
>> RAID-5 conversion, but once it's done I believe the file system itself
>> will still be 250GB so I'll need to resize the file system. In the
>> past I've done this with gparted, which seems to work fine, but this
>> time I was considering doing it at the command line. Does anyone know
>> of a good web site that goes through how to do that? I've browsed
>> around and found different pages that talk about it but my reading
>> looks like they all have minor differences which leaves me a bit
>> worried.
>
> Using cfdisk or fdisk, delete the partition and recreate it, USING THE
> SAME START BLOCK at a larger size.
>
> Then "resize2fs /dev/sdwhatever" will resize the filesystem to fill the
> partition.
Silly question, but is there really a need for a partition in a
scenario like that? He could conceivably move the data to the
beginning of the block device, and then run resize2fs.
Less silly question: What would an effective means of moving the data
on-disk like that be? Something like:
dd if=/dev/md0 of=/dev/md0 skip=$count_of_blocks_to_get_to_fs_start
would do it, I think, since you wouldn't be overwriting any block
unless it was useless or already moved. Better not interrupt it unless
you can recalculate the skip and seek parameters, though.
That'd default to moving data 512 bytes at a time, though, which would
be slow and painful. You could do something like
dd if=/dev/md0 of=/dev/md0 skip=$fs_start count=$boundary_pos
dd if=/dev/md0 of=/dev/md0 bs=4M skip=$resume_read_pos seek=$resume_write_pos
where:
fs_start = # the block number to where the filesystem begins
boundary_pos = # how many increments of 512 bytes it would take to get
to a nice round number like 4M
resume_read_pos = # how many increments of 4MB it would take to get
back to where we left off reading
resume_write_pos = # how many increments of 4MB it would take to get
back to where we left off writing
I don't know what the exact values for these would be, though.
--
:wq
reply other threads:[~2011-11-17 17:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+czFiA71zrEev+_vV9-cD8RB_AipeTKD7PkbkZdGdGrjUznyA@mail.gmail.com \
--to=mikemol@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox