On Sat, Feb 23, 2019 at 06:32:43PM +1100, Andrew Greig wrote:
> > 1. unmount both of them
>
> $sudo umount /dev/sdb1 && umount /dev/sdc1 ?
or "sudo umount /data0 /data1"
as long as no process has any file open under those directories (and that
includes having a shell with it's current working directory in either of
them - you can't unmount a filesystem that is being actively used), both
directories will be unmounted.
> > 2. remount ONE of them (say, data0) as /data (and edit /etc/fstab so that it
> > gets mounted as /data on every reboot. also delete the line in fstab that
> > mounts data1).
>
> Here is my current fstab (please note, partition manager took me an hour and
> a half to negotiate and I was unable to install swap on my SSD so I put a
> swap partition on each of the two SATA drives so that they would be exactly
> the same size. )
That's a shame because swap on SSD is much faster than swap on HDD. Of course
when you upgrade your RAM, it probably won't swap much.
Once you get your RAM upgrade installed, I strongly recommend that you install
libvirt and virt-manager and create some VMs to play with. e.g. make a VM and
give it three 5GB disk image files (i.e. similar to your current system with
three drives).
Then install ubuntu onto it. you can mess around with the partition manager
(or even fdisk on the command line) until you understand how it works without
risking anything on your real system. and try different variations on the
build (e.g. install ubuntu onto one of the VM's virtual disks, boot it up,
and then manually partition the other two virtual disks and aformat them with
btrfs and add them to fstab. and experiment also with other filesystems and/or
mdadm and/or lvm2 if you like).
That's one of the things VMs are good for, to experiment and test things and
especially to learn. In fact, they're an excellent way to learn stuff. Things
like partition management and formatting partitions are hard and a bit scary
because they are things that are very rarely done by most people - only when
building a new machine or adding new drives to a machine. Practice is the only
thing that will make it familiar and comfortable. Do this every few months
to keep the memory fresh so that you will know what to do and how to do it
if/when you ever need to.
> # /data0 was on /dev/sdb2 during installation
> UUID=0e8718c8-03bf-4f1a-915f-df03fe117dc0 /data0 btrfs defaults 0
> 2
edit this line, change data0 to data.
> # /data1 was on /dev/sdc2 during installation
> UUID=5969127b-f5e0-40dc-98ba-ea7252c9ee41 /data1 btrfs defaults 0
> 2
delete or comment out this line.
then, save & exit, and run "sudo mount /data"
> # /efi was on /dev/sda1 during installation
> UUID=b588608e-8cf7-43be-8a53-03dfde6f8f15 /efi btrfs defaults 0
> 2
the EFI partition should be FAT32. UEFI can't use btrfs. I guess that means
it's not being used at all - your machine is either old-fashioned BIOS or, if
UEFI, it's configured for legacy (BIOS) boot.
> > 3. destroy the partition table on the data1 drive, and recreate it (again,
> > one big partition for the entire disk[1])
>
> So by deleting the partition we eliminate the FS (btrfs) and in the addition
> step the FS is rebuilt?? but specifically to control both disks?
No, it's just deleting and re-creating the partition. creating a partition and
formatting it are two different things. A partition is just a chunk of disk
space reserved for some particular use. That use can be to be formatted as
one of several different filesystems (ext4, xfs, btrfs, fat32, etc etc), to be
used as swap space, for an lvm physical volume (PV), or just left unused.
But now that i know you've got a swap partition on there, DON'T DELETE THE
ENTIRE PARTITION TABLE. Just delete /dev/sdc2. better yet, don't bother
deleting it at all, this step can be skipped.
You can actually skip step 3 entirely: the '-f' option used in step 4 ('btrfs
device add -f ...') should force it to use /dev/sdc2 even though it is already
formatted as btrfs.
> Can /dev/sdc2 can be deleted with gparted?
yes.
> > 4. add that drive to the existing btrfs array on /data
> >
> > e.g. *IF* /data1 was sdc1, you'd do something like:
> >
> > sudo btrfs device add -f /dev/sdc1 /data
> > sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /data
change sdc1 here to sdc2.
> > The earlier you do this (i.e. the less data is already on it), the faster
> > this conversion to raid1 will be. Nearly instant if there's little or no
> > data. Much longer if there's a lot of data that needs to be synced to the
> > other drive.
> >
> > i.e. best to do it before copying the data from your old drive.
>
> I have about 4Gb only of data from this morning's photo shoot, I can move
> that back to /home/andrew easily enough. I just tried the Data drive to see
> how my CHOWN went. ( I cheat, I use mc)
No need. 4GB of data will be synced in very little time.
craig
--
craig sanders <[email protected]>
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
