[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for comments on new disk installation plan



Reid Priedhorsky <reid@reidster.net> writes:

> I'm about to enter the modern age and replace my 3.2G primary disk with a
> 160G model. Moving all my data, etc., is going to be fairly involved, so
> I would be very appreciative of any comments you all might have on my
> partitioning scheme and/or my transition plan.

As said in my other post and by others on this list, do consider using
LVM.  Oh, I forgot in my other posting: You don't have to upgrade your
2.4 kernel to use LVM.  If you use the debian kernel, it has the
device mapper (which replaces LVM in the kernel) already patched in.
Otherwise, you can patch your standard 2.4 kernel quite easily with
the device mapper patches and use the debian LVM2 user space tools
package.  If you don't use the debain kernel and don't want to patch,
you can still use the standard LVM in the vanilla 2.4 kernel and the
LVM1 user space tools, for which there's also a debian package.

Also, I like /tmp on a tmpfs instead of a hard disk.  tmpfs uses the
RAM and swap space to store files.  This is very nice, especially,
when you have some apps that work with large temp files and other apps
that use large virtual memory.  tmpfs unifies this.  The disk space
that you planned to allocate for /tmp can then better be used for swap
space.

> Filesystem copying plan:
> 
>   [ ] copy source to destination using "rsync -aHtx --progress"
>   [ ] "ls -lR > foo.txt" of source partition
>   [ ] "ls -lR > bar.txt" of destination partition
>   [ ] "diff -u foo.txt bar.txt | less", check for problems

I have several times copied file systems and didn't like the rsync or
cp or tar or cpio or whatever method, because it changes the ctime
time stamps of all files and maybe the mtime and owner of symlinks
(depending the tool's ability to set mtime and owner of a symlink).

I prefer doing the copying with dd, i.e.

    dd if=/dev/source-blk-dev of=/dev/destination-blk-dev

This requires the destination to be at least the size of the source.
If the destination is larger than the source you can do a

    fsck -f /dev/destination-blk-dev
    resize2fs /dev/destination-blk-dev

after copying, to use the full space.  If you have LVM, you can choose
the size of all logical volumes (the block devices where you put your
file systems) independent of any geometry issues of your drives,
i.e. you can easily set the destination block device to exactly the
same size as the source block device.

urs



Reply to: