[GRLUG] duplicate usb drive

[Bill Littlejohn]

Thanks all!


Michael Mol wrote:
> On 8/30/06, Bill Littlejohn <billl at mtd-inc.com> wrote:
>   
>>  I'm a little confused.
>>  "You can correct the partition table with parted or fstab after it's
>> done.".
>>  What do you mean by "correct"?
>>  I've used guiparted in Knoppix but not much else. I usually use Partition
>> Commander.
>>     
>
> That's what he's referring to. (Though I'm not sure your version of
> parted supports resizing NTFS.  Not all do...I'm not sure any do.)
>
>   
>>  I'm also a little confused on the purpose of using fdisk and ntfsresize
>> after transferring the image.
>>     
>
> If the target drive is larger than the source drive, you may want to
> expand your filesystem to take advantage of the extra space.  Before
> you can run ntfsresize, the partition the NTFS filesystem resides on
> has to be expanded.  That's what fdisk is for.
>
> You could also use fdisk to create a new partition in the empty space,
> and use Windows to create an NTFS partition on that.
>
> Finally, you could just stick with a straight dd, and not bother with
> that extra space.  Whatever works. :)
>
>   
>>  "
>>  dd if=/dev/sda of=/dev/sdb bs=4000000
>>  fdisk /dev/sdb
>>  ...
>>  ntfsresize /dev/sdb1
>>  "
>>  I know I'm being somewhat dense here - a little hand-holding would be
>> appreciated.
>>     
>
> * dd
> "if" points to the input file
> "of" points to the output file
>
> ...but you probably knew those.
>
> "bs" allows you to specify the block size.
>
> When dd copies data, it does it a certain number of bytes at a time.
> When the Linux kernel copies data, it also processes data a certain
> number of bytes at a time.  There's a little bit of overhead each time
> dd or the Kernel processes a new block of data, which slows down the
> transfer a little bit.
>
> We can't control how much data the Kernel processes, since that's
> device-specific.  We can, however, tell dd to processes data in block
> sizes specified by "bs".  By doing that, we significantly reduce the
> fragmentation of the operation in user space.
>
> Ideally, we would want dd and the kernel to process data in same-size
> chunks, but it's non-obvious exactly how much data the kernel is
> willing to process at once. (And that's called an "atomic" operation,
> for what it's worth. I seem to recall a number of 2KB, from somewhere
> in the glibc info pages, but that was a long time ago.)
>
> $ dd if=debian/boot.bin of=/dev/fd0 bs=512
>
> The above command line would copy data out of a Debian boot floppy
> image and write it to the floppy device, 512 bytes at a time.
>
> $ dd if=/dev/sda of=/dev/sdb
>
> The above command line would copy data from /dev/sda to /dev/sdb.  We
> didn't specify a block size, so I don't know how many bytes it will
> transfer at a time.  However, it will continue to transfer data until
> it exhausts /dev/sda, or until it runs out of space on /dev/sdb.
>
>   
>>  :)
>>  Bill
>>     
>
> Mike
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20060830/57a74266/attachment-0001.htm